> Exactly what is wrong with doing fsync() on the
> directory ?
Nothing, except that it requires source code changes to every
application which expects BSD semantics for these operations.
Anecdotal evidence suggests at least the MTA authors are resistant to
making such changes.
> Why do you want us to turn link() and rename()
> into link_slowly() and rename_slowly() ?
I don't by default, only as an option. You know, just like "chattr
-S" or "mount -o sync" means do_everything_slowly().
> Why can't you use a simple wrapper function to
> do this for you ?
It would not be all that simple; it would have to parse the arguments
to figure out the containing directories, open() a file descriptor on
each, and fsync() them. Not impossible, but it does introduce several
those additional system calls as performance hits and points of
failure, not to mention possible race conditions.
Still, I suppose you could do this well enough in the C library. You
might even want it to be the default when "__USE_BSD" is defined or
something.
But it still seems simpler to me just to make it an option in the file
system.
In your next message, you say:
> Besides BSD softupdates and the various journaling
> filesystems which are in use on other Unixen also
> don't provide the 4.3BSD solution any more ...
This surprises me if it is true; do you have a reference? And what
mechanism *do* the modern BSDs provide to commit metadata changes to
disk?
- Pat
-
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/