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

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

Posted Mar 13, 2009 16:25 UTC (Fri) by droundy (subscriber, #4559)
In reply to: Ts'o: Delayed allocation and the zero-length file problem by welinder
Parent article: Ts'o: Delayed allocation and the zero-length file problem

Similarly, all FSs should try hard to make sure open-write-close-rename leaves you with either the new or the old file. Anything else isn't reasonable.

Absolutely. The problem with the argument that it must be open-write-fsync-close-rename is that that describes a *different* goal, which is to ensure that the new file is actually saved. When an application doesn't particularly care whether the new or old file is present in case of a crash, it'd be nice to allow them to ask only for the ordinary POSIX guarantees of atomicity, without treating system crashes as a special exception.

And on top of that, I'd prefer to think of all those Ubuntu gamers as providing the valuable service of searching for race conditions relating to system crashes. Personally, I prefer not to run nvidia drivers, but I'd like to use a file system that has been thoroughly tested by hard rebooting the computer, so that on the rare power outages, I'll not be likely to lose data. It'd be even nicer if lots of people were to stress-test their ext4 file systems by simply repeatedly hitting the hard reset button, but it's hard to see how to motivate people to do this.

---

(Log in to post comments)