> If the file has gone away, the filesystem should just say so. "No such
> file or directory" is a perfectly good return value from a file server,
> and is very non-confusing when the user has tried to write to a file that
> somebody else moved from another client. You can explain it to the casual
> computer user, and he will understand it. He will realize that it was the
> users actions that caused it.
>
> Contrast this to the silly stuff a good NFS server has to do in order to
> avoid the notion of stale filehandles after a reboot. That's just not
> right. And it's fundamentally because it doesn't think pathnames are
> important.
Linus,
Thanks for the clarification. I think we're on the same wavelength.
Yes, its better if the client retains some notion of the pathname
that it used to obtain a filesystem object. At the very least,
if the client gets a "stale" error from the server, it can try
to re-evaluate the pathname if the app is trying to open the
file - and return an ENOENT if it fails.
In Solaris we maintain the pathname from the mountpoint for
every replicated mount. If a replica server fails, the
client switches to a replica and uses the pathname for each
object to obtain a filehandle from the new replica server.
This works with any NFS v2 or v3 server.
No doubt, this would be quite easy to implement with the
dentry scheme in the Linux kernel.
In NFS version 4 we've got the notion of "volatile" filehandles
that can be used by user-level servers that have no ability
to map an fsid/inode to a file descriptor. An NFSv4 client
is expected to retain the pathname so that it can get a new
filehandle if a volatile filehandle expires.
In summary: filehandles are useful at the protocol level, but it's
good for clients to retain pathnames if they need to recover
filehandles.
Brent
-
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 : Mon May 15 2000 - 21:00:26 EST