> 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. > I think there might be a mis-understanding about the example (reproduced below) and about SOMC. The relationship that matters is not whether X happens before Y. The relationship between X and Y is that they are in the same directory, so fsync(new file X) implies fsync(X's parent directory) which contains Y. In the example, X is A/foo and Y is A/bar. For truly un-related files such as A/foo and B/bar, SOMC does indeed allow fsync(A/foo) to not persist B/bar. touch A/foo echo “hello” > A/foo sync mv A/foo A/bar echo “world” > A/foo fsync A/foo CRASH We could rewrite the example to not include fsync, but this example comes directly from xfstest generic/342, so we would like to preserve it. But in any case, I think this is beside the point. If ext4 does not want to provide SOMC-like behavior, I think that is totally reasonable. The documentation does *not* say all file systems should provide SOMC. As long as the documentation does not say ext4 provides SOMC-like behavior, are you okay with the rest of the documentation effort? If so, we can send out v3 with these changes. Please forgive my continued pushing on this: I would like to see more documentation about these file-system aspects in the kernel. XFS and btrfs developers approved of the effort, so there is some support for this. We have already put in some work on the documentation, so I'd like to see it finished up and merged. (Sorry for hijacking/forking the thread Amir!)
