Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Ts'o: Delayed allocation and the zero-length file problem

Posted Mar 14, 2009 14:20 UTC (Sat) by endecotp (guest, #36428)
In reply to: Ts'o: Delayed allocation and the zero-length file problem by nix
Parent article: Ts'o: Delayed allocation and the zero-length file problem

That's interesting, but there are two ways to look at it:

- Since mv doesn't fsync and mv is expected to leave things in a sane state after a crash, the kernel must be expected to "do the right thing" wrt rename().

- Since mv doesn't sync, mv is not guaranteed to leave things in a sane state after a crash; if you thought that it was guaranteed to do so you were wrong.

(Log in to post comments)

Both

Posted Mar 14, 2009 15:25 UTC (Sat) by man_ls (subscriber, #15091) [Link]

What I read from this very interesting discussion is that both assumptions are right depending on the circumstances. An inherently unsafe fs like ext2 is not expected to guarantee anything, and mv on ext2 may be left in a unstable state after a crash (including zero-length files). Coreutils developers probably did not see fit to fsync since it would not increase the robustness significantly in these cases: the system might crash in the middle of the fsync anyway.

But on a journalled fs like ext3 users will expect their system to be robust in the event of a crash -- and as the XFS debacle shows, not only for metadata. Both are POSIX-compliant, only ext3 is held to higher standards than ext2. What this means for ext4 is obvious.