Hi,
On Fri, Aug 03, 2001 at 05:47:17PM +0200, Daniel Phillips wrote:
> > As far as the fsync semantics are concerned. Yeah, they would be useful,
> > but only to avoid one directory fsync call that will tell the kernel
> > _exactly_ what the process wants instead of letting it figure it out by
> > itself.
>
> No, it's not just that. It's not enough to fsync just the parent, the
> parent's parent may have been relinked and not comitted. Also, the
> kernel has the advantage of the locked chain of dcache entries
> available to it.
Not necessarily. If the file has been hard-linked and then the
original link removed, we don't have a valid dcache entry any more
(and yes, this is a common construct for some applications --- it is
often used to work around NFS atomicity problems.)
An MTA using such a construct and expecting fsync to do the right
thing will *not* work if you follow the dcache chain on fsync as you
propose here.
> We don't need all the paths, and not any specific path, just a path.
Exactly, because fsync makes absolutely no gaurantees about the
namespace. So a lost+found path is quite sufficient.
Cheers,
Stephen
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:27 EST