| |||||||||||||
An interesting linkAn interesting linkPosted Mar 13, 2009 5:46 UTC (Fri) by qg6te2 (guest, #52587)In reply to: An interesting link by bojan Parent article: ext4 and data loss
On slide 84 the following idealistic assertion is made:
(Log in to post comments)
An interesting link Posted Mar 13, 2009 6:08 UTC (Fri) by bojan (subscriber, #14302) [Link]
> The ext3 ordered mode should be the rule as how filesystem should behave, not the exception.
It's not even the rule for ext3. You can easily switch to writeback and get:
> Data ordering is not preserved - data may be written into the main file system after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal file system integrity, however it can allow old data to appear in files after a crash and journal recovery.
There must be dozens of other file systems in all sorts of POSIX compatible OSes that don't behave that way (i.e. data=ordered). So, fixing one file system isn't going to be good enough solution, I think.
What's wrong with applying correct idioms in applications, the way emacs (and vim?) do?
An interesting link Posted Mar 13, 2009 6:57 UTC (Fri) by qg6te2 (guest, #52587) [Link] What's wrong with applying correct idioms in applications, the way emacs (and vim?) do?A simple "write data to disk" operation would have unnecessary complexity, as the slides show (a collection #ifdefs and run-time ifs). This is insane. The operating system (and hence by extension, the underlying filesystem) is supposed to abstract things away, not make things harder. A sane filesystem should have the previous version of a file available intact, no matter when the crash occurred. To put it another way, why replicate the "safe save" functionality in each app when it can be done once in the filesystem ?
An interesting link Posted Mar 13, 2009 10:41 UTC (Fri) by bojan (subscriber, #14302) [Link]
> A simple "write data to disk" operation would have unnecessary complexity, as the slides show (a collection #ifdefs and run-time ifs). This is insane. The operating system (and hence by extension, the underlying filesystem) is supposed to abstract things away, not make things harder.
Unfortunately, that's the status of POSIX right now. And the complexity can be put into a library for everyone to share.
> A sane filesystem should have the previous version of a file available intact, no matter when the crash occurred. To put it another way, why replicate the "safe save" functionality in each app when it can be done once in the filesystem ?
Because the reality is that right now POSIX doesn't demand it, so your app is bound to bump into a file system here and there that requires exactly that. An app written safely will work with both types of file system semantics. The opposite is not true.
An interesting link Posted Mar 15, 2009 13:53 UTC (Sun) by kleptog (subscriber, #1183) [Link]
ISTM that the choice for the application writer is straightforward:
1. I care that my application works correctly in the face of crashes on Linux on the default filesystem, in which case the above fixes will do it.
2. I care that my application works correctly in the face of crashes on any POSIX compliant OS, in which case you need to fix the app.
Unfortunately I come across a lot of code where the writer didn't even consider the problem, leaving bogus state even if you just kill the application at the wrong moment. I sincerely hope this brouhaha will at least cause more people to pay attention to the issue.
An interesting link Posted Mar 15, 2009 18:08 UTC (Sun) by skybrian (subscriber, #365) [Link]
Agreed that carefully written, standards-compliant apps that go the extra mile to avoid data loss regardless of operating system will have a portability advantage over most. But unless there are lots of users out there running on filesystems with weaker semantics than ext3, the advantage isn't that big.
Also, what the most carefully written apps do isn't particularly relevant to what the filesystem should do. The choice for filesystem writers is:
a) implement just the bare standards, and most people won't use your filesystem because their apps lose data, even if it's faster.
b) implement nicer semantics so that people will actually prefer your filesystem over others. Decreased data loss after a system crash, even for poorly written apps, is such a feature.
It's the same tradeoff that exists for people who write web browsers. When the standards are too weak to achieve compatibility with most apps, you have to go beyond them. You need both good performance and good compatibility.
Without this patch, ext4 would not be competitive with ext3.
|
|||||||||||||