> > As I wrote to Dave, if file is not "metadata dirty" before rename, > > then whether or not rename dirties to file for fsync is a filesystem > > specific implementation detail that is not in any standard. > > > > Since filesystems tend to try to optimize out unneeded journal > > commits, so the observation about what filesystems do today > > empirically is not a sufficiently strong argument. > > Even if the strictly ordered metadata guarantees Dave explained so > many time before is not formally defined anywhere, > I think it's a behavior that shouldn't change, as not only it makes > sense, but applications might be relying on it and therefore > useful to make sure no regressions happen. If such tests should be > shared (and run only filesystems known to support > the strictly ordered metadata) or require something special, is > another question. > I agree with you that it is good to test and verify those semantics. I was not arguing against assuming strictly ordered metadata. I was arguing against assuming that rename marks the inode dirty. If rename does not mark the inode dirty, then fsync(file) may be optimized away by filesystem and will not require persisting anything, without breaking strictly ordered metadata semantics. > > > > Again, if your test can afford to do fsync of file and parent dir > > it is best to be on the safe side (please audit other similar tests > > that you know about). If your test cannot afford to fsync parent > > dir, then at least a fat comment about this issue is worth about > > the expected (but not guaranteed) effects of fsync of file. > > I'm sending a v2 with the fsync against the parent directory, despite > not being needed for any fs I could > run the tests against, because it's a generic test. ACK. Thanks, Amir.
