On 01/09/2011 01:56 PM, Thomas Bellman wrote:
That particular problem was solved with the introduction of the rename(2) system call in 4.2BSD a bit more than a quarter of a century ago. There is no need to introduce another, less flexible, API for doing the same thing.
I'm curious if there are any BSD specifications that state that rename() has this behavior. Ted Tso has been claiming that POSIX does not require this behavior in the face of a crash and that as a result, an application that relies on such behavior is broken, and needs to fsync() before rename(). This of course, makes replacing numerous files much slower, glacially so on btrfs. There has been a great deal of discussion ok the dpkg mailing lists about it since plenty of people are upset that dpkg runs much slower these days than it used to, because it now calls fsync() before rename() in order to avoid breakage on ext4.
You can read more, including the rationale of why POSIX does not require this behavior at http://lwn.net/Articles/323607/.
I still say that preserving the order of the writes and rename is the only sane thing to do, whether POSIX requires it or not.
-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
