Removing ext2 and/or ext3

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

> This hack does make the file safe across rename during power failure for ext4.

That's simply not true, sadly. If I understand correctly, the patch[1] makes the race window shorter but does not eliminate it[2].

[1] v2.6.30-rc1~416^2~15 (ext4: Automatically allocate delay allocated blocks on rename, 2009-02-23)
[2] https://bugzilla.kernel.org/show_bug.cgi?id=15910

Removing ext2 and/or ext3

Posted Feb 11, 2011 21:28 UTC (Fri) by zlynx (guest, #2285) [Link] (2 responses)

From that, it looks as if the ext4 maintainers didn't follow up with what they claimed the patch would do.

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) [Link] (1 responses)

> 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.

Delayed allocation safety

Posted Feb 11, 2011 23:43 UTC (Fri) by zlynx (guest, #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.
---- 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.