User: Password:
|
|
Subscribe / Log in / New account

Removing ext2 and/or ext3

Removing ext2 and/or ext3

Posted Feb 11, 2011 18:50 UTC (Fri) by dlang (subscriber, #313)
In reply to: Removing ext2 and/or ext3 by zlynx
Parent article: Removing ext2 and/or ext3

unfortunately your recommendation does not protect the file in the case of a power failure.

if you want your rename to be safe across a crash/power failure you need to do a fsync.

there have been some hacks added to some filesystems to try and detect this to make it safer, but safer != safe

yes, ext3 let you get away with things like this (at least in the most common case), but no other filesystem on any *nix OS does.

the Unix spec says that renames are atomic, but that's only talking about a running system, not across a crash


(Log in to post comments)

Removing ext2 and/or ext3

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

This hack does make the file safe across rename during power failure for ext4. That's all I meant. It's always been safe in ext3 in ordered mode.

Either the file named X will contain new contents or old contents. It will never be blank or half written.

Again this only applies to ext3 and ext4, and only in ext4 after kernel 2.6.30.

Removing ext2 and/or ext3

Posted Feb 11, 2011 21:20 UTC (Fri) by jrn (subscriber, #64214) [Link]

> 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 (subscriber, #2285) [Link]

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]

> 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 (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.
---- 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 © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds