Not logged in
Log in now
Create an account
Subscribe to LWN
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
PostgreSQL 9.3 beta: Federated databases and more
Allocate on rename is different from write on rename. All the discussions I followed claimed it would write the data before writing the rename.
I wonder why they thought allocate would be sufficient? Seems like they didn't listen to the users after all.
Delayed allocation safety
Posted Feb 11, 2011 23:28 UTC (Fri) by jrn (subscriber, #64214)
I think they did. There is nodelalloc for those who expect frequent crashes or do not want delayed allocation for some other reason. There is that hack to make 0-length files rare. And updating files using the common rename idiom does not force a painfully slow journal commit like it did in ext3 with data=ordered.
Meanwhile there is more awareness among application developers about the need to use fsync or fdatasync for data updates that need to persist and not to use those functions for updates that are not so crucial. So apps are finally doing the right thing on ubifs and hfs+.
So at least this ext4 user wouldn't have it any other way.
Posted Feb 11, 2011 23:43 UTC (Fri) by zlynx (subscriber, #2285)
So you end up with:
1. Space allocated for the new file.
2. Directory written to disk with new filename.
---- CRASH HAPPENS HERE
3. New file contents written to disk.
The sequence of events above is hardly better than it was before the fix.
Did I miss something in the sequence?
Just don't allow step 2 to happen before step 3 and everyone would have been happy.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds