Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
An interesting link
Posted Mar 13, 2009 5:46 UTC (Fri) by qg6te2 (guest, #52587)
Posted Mar 13, 2009 6:08 UTC (Fri) by bojan (subscriber, #14302)
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?
Posted Mar 13, 2009 6:57 UTC (Fri) by qg6te2 (guest, #52587)
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 ?
Posted Mar 13, 2009 10:41 UTC (Fri) by bojan (subscriber, #14302)
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.
Posted Mar 15, 2009 13:53 UTC (Sun) by kleptog (subscriber, #1183)
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.
Posted Mar 15, 2009 18:08 UTC (Sun) by skybrian (subscriber, #365)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds