Reliable, fast rename replacements

Posted Apr 1, 2009 5:51 UTC (Wed) by butlerm (subscriber, #13312)
Parent article: From ext3 to ext4: An Interview with Theodore Ts'o (Linux Magazine)

There is a relatively simple solution here that would allow ext4 to be both
fast and reliable in this case - i.e. never truncate files on crashes after
rename replacements without being forced to commit all data from the
replacement to disk before finishing the rename.

It simply involves putting rename replacement undo records in the
filesystem journal, and on recovery, after rolling the journal forward,
undo-ing any rename replacements for which the data of the replacement
version did not make it to disk. See discussion in comments to Ted's
recent blog entries on the subject for more information.

This could be done with O_TRUNC too, but that would be much more complex,
and contra-Linus I don't see how anyone can rationally expect not to get a
zero length file on recovery if an application explicitly specifies that is
what it wants (before proceeding further).

Reliable, fast rename replacements

Posted Apr 1, 2009 6:48 UTC (Wed) by bojan (subscriber, #14302) [Link]

Very cool. So, with this, we'd get full delayed allocation (i.e. removal of workarounds) and any renamed files with zero blocks would have their old versions resurrected. Correct?

Reliable, fast rename replacements

Posted Apr 3, 2009 21:43 UTC (Fri) by spitzak (guest, #4593) [Link]

This sounds like the correct solution to me and perhaps it is interesting and "pure" enough that Tso would feel like doing it.

My opinion on this: POSIX guarantees if you write & close a file and rename it, anybody trying to open the destination name will either see the old data or the new data, not anything else (such as an empty file). POSIX says "I don't guarantee anything on a crash". But the whole point of ext4 is to "guarantee" something. I do not see any logical reason for this guarantee to be something other than what POSIX guarantees while it is running. So the current behavior of ext4 on a crash is wrong.

(追記) (追記ここまで)