[file name must be flushed on fsync()]
> I don't know why it is hard or inefficient to implement this at the VFS
> level, though I'm sure there is a reason or this thread wouldn't
> exist. Stephen, perhaps you could explain for the record why sys_fsync
> can't just walk the chain of dentry parent links doing fdatasync? Does
> this create VFS or Ext3 locking problems? Or maybe it repeats work
> that Ext3 is already supposed to have done?
Well, the course was that I asked whether ext3 would do synchronous
directory updates, and some people jumped in and said that one should
fsync() the parent directory, however, since we figure from SUS, that's
invalid.
After some forth and back, we finally figured that at least ext2 is
implementing fsync() improperly.
So this part is covered.
The other thing is, that Linux is the only known system that does
asynchronous rename/link/unlink/symlink -- people have claimed it might
not be the only one, but failed to name systems.
So we need to assume that Linux is the only system that does
asynchronous rename/link/unlink/symlink, however a directory fsync() is
believed to be rather expensive.
Still, some people object to a dirsync mount option. But this has been
the actual reason for the thread - MTA authors are refusing to pamper
Linux and use chattr +S instead which gives unnecessary (premature) sync
operations on write() - but MTAs know how to fsync().
> The prescription for symlinks is, if you want them safely on disk you
> have to explicitly fsync the containing directory.
Yes, and it doesn't matter, since MTAs don't use symlinks (symlinks
waste inodes on most systems).
-- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/