Become a fan of Slashdot on Facebook


Forgot your password?
Last Chance - Get 15% off sitewide on Slashdot Deals with coupon code "BLACKFRIDAY" (some exclusions apply)". ×

Comment Re:Wrong question (Score 1) 289

Hear, hear. That's exactly the problem. The invariant of rename is useful, and it is useful to be able to get the atomic cutover without ensuring that the file is on disk. The previous ext4 behaviour is utterly useless to everyone. The reason is that there is an important case that hasn't been raised much: where the process doing the renaming isn't the process doing the writing. Consider:

$ echo "Hello, world" > # or some other operation that produces
$ mv file
$ [System crashes some time after mv completes.]

In this case, the shell probably doesn't do an fsync before it closes, so the bug might appear. Basically, the implication of not solving this is the kernel is that every application that writes a file needs to be changed to fsync before closing it, if someone else might later want to rename it over another file. That is equivalent to an enforced fsync_on_close flag, but also requires that every application is changed, and it completely wipes out the lazy allocation, write-behind optimisation that this was all supposed to allow. The only realistic possibility is for mv to open and fsync it before renaming, but that's racy, so the kernel is the only place where this problem can be fixed properly.

Money is better than poverty, if only for financial reasons.