| |||||||||||||
Atomicity vs durabilityAtomicity vs durabilityPosted Mar 15, 2009 10:18 UTC (Sun) by bojan (subscriber, #14302)In reply to: Atomicity vs durability by alexl Parent article: Ts'o: Delayed allocation and the zero-length file problem
> (Notice how this has no separation about "filenames" and "data")
Notice how it doesn't say _anything_ at all about the content of the file _on_ _disk_ that is being renamed into the old file. That is because in order to see the file _durably_, you have to commit its content. Completely unrelated to committing the _rename_.
Just because another process can see the link (and access the data correctly, which may still just be cached by the kernel) does _not_ mean data reached the disk yet.
BTW, thanks for working on fixes of this in Gnome.
(Log in to post comments)
Atomicity vs durability Posted Mar 15, 2009 10:29 UTC (Sun) by alexl (subscriber, #19068) [Link]
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.
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).
|
|||||||||||||