A proper solution would involve allowing the filesystem to update names that
have been exported outside the filesystem via an interface that both the
importer and exporter would have to know how to support. That is, the
filesystem would tell whoever is holding the exported name to change the name.
It is on the ReiserFS wish list for some future date. If you agree, we'll
send you a patch in a year or so when we implement the repacker that will
change keys around so as to optimize performance. The problem is of course
that none of the network filesystems support such an interface, though
they should....
Hans
Linus Torvalds wrote:
>
> On Mon, 15 May 2000, Alan Cox wrote:
> > > In summary: filehandles are useful at the protocol level, but it's
> > > good for clients to retain pathnames if they need to recover
> > > filehandles.
> >
> > How do you know the recovered pathname is the same file ?
>
> Don't expect UNIX semantics from a networked filesystem.
>
> Instead, expect _sane_ semantics. The same way you have to do magic things
> for NFS locking if you're a mail client that wants to handle atomicity, a
> networked filesystem doesn't have to try to maintain exact UNIX behaviour.
>
> A sane definition of "same file" over a network is, after all, "same
> naming". What more is there?
>
> If you're thinking "same inode", then you're not thinking about a
> networked filesystem. You're thinking about a distributed UNIX filesystem.
> Which is a different thing.
>
> To get "same file" semantics, you acquire a lease on the file. There's no
> question about that. But that is an issue that has nothing at all to do
> with the _name_ of the file, whether that be a ASCII pathname or a
> "filehandle". Understand that. A "lease" on a file is a real thing, and
> gives you the guarantees you want - and has absolutely nothing to do with
> naming.
>
> Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:14 EST