| |||||||||||||
Atomicity vs durabilityAtomicity vs durabilityPosted Mar 15, 2009 10:29 UTC (Sun) by alexl (subscriber, #19068)In reply to: Atomicity vs durability by bojan Parent article: Ts'o: Delayed allocation and the zero-length file problem
Of course not. It says *nothing* about whats on disk, because durability wrt system crashes (not process crashes) is not part of the POSIX. So, any behaviour better than full data loss on crash is a robustness property of the implementation.
I argue that a robust useful filesystem should give data-before-metadata-on-rename guarantees, as that would make it a better filesystem. And without this guarantee I'd rather use another filesystem for my data. This is clearly not a requirement, and important code should still fsync() to handle other filesystems. But its still the mark of a "good" filesystem.
(Log in to post comments)
Atomicity vs durability Posted Mar 15, 2009 10:37 UTC (Sun) by bojan (subscriber, #14302) [Link]
Similarly, any file system that on fsync() locks up for several seconds is not a very good one ;-)
Atomicity vs durability Posted Mar 15, 2009 11:04 UTC (Sun) by man_ls (subscriber, #15091) [Link] That is why we are willing to replace it in the first place! but not if it means losing in the process its good properties (be them in the spec or not).
Atomicity vs durability Posted Mar 20, 2009 11:24 UTC (Fri) by anton (guest, #25547) [Link] Similarly, any file system that on fsync() locks up for several seconds is not a very good one ;-)If the fsync() has to write out 500MB, I certainly would expect it to take several seconds and the fsync call to block for several seconds. fsync() is just an inherently slow operation. And if an application works around the lack of robustness of a file system by calling fsync() frequently, the application will be slow (even on robust file systems).
|
|||||||||||||