User: Password:
Subscribe / Log in / New account

Delayed allocation safety

Delayed allocation safety

Posted Feb 11, 2011 23:28 UTC (Fri) by jrn (subscriber, #64214)
In reply to: Removing ext2 and/or ext3 by zlynx
Parent article: Removing ext2 and/or ext3

> Seems like they didn't listen to the users after all.

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.

(Log in to post comments)

Delayed allocation safety

Posted Feb 11, 2011 23:43 UTC (Fri) by zlynx (subscriber, #2285) [Link]

What I gathered from the bug report is that the allocation will take place but the data is still in limbo when the rename is written to disk.

So you end up with:
1. Space allocated for the new file.
2. Directory written to disk with new filename.
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 © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds