On Thu, May 02, 2019 at 10:15:01PM -0500, Vijay Chidambaram wrote: > > A few things to clarify: > 1) We are not suggesting that all file systems follow SOMC semantics. > If ext4 does not want to do so, we are quite happy to document ext4 > provides a different set of reasonable semantics. We can make the > ext4-related documentation as minimal as you want (or drop ext4 from > documentation entirely). I'm hoping this will satisfy you. > 2) As I understand it, I do not think SOMC rules out the scenario in > your example, because it does not require fsync to push un-related > files to storage. > 3) We are not documenting how fsync works internally, merely what the > user-visible behavior is. I think this will actually free up file > systems to optimize fsync aggressively while making sure they provide > the required user-visible behavior. As documented, the draft of the rules *I* saw specifically said that a fsync() to inode B would guarantee that metadata changes for inode A, which were made before the changes to inode B, would be persisted to disk since the metadata changes for B happened after the changes to inode A. It used the fsync(2) *explicitly* as an example for how ordering of unrelated files could be guaranteed. And this would invalidate Park and Shin's incremental journal for fsync. If the guarantees are when fsync(2) is *not* being used, sure, then the SOMC model is naturally what would happen with most common file system. But then fsync(2) needs to appear nowhere in the crash consistency model description, and that is not the case today. Best regards, - Ted
