On Mon, 15 May 2000, Brent Callaghan wrote:
>
> > there are some really good reasons for using dentries: a _sane_ network
> > filesystem will do everything based on an explicit pathname, and this
> > "filehandle" crap that NFS uses is only another breakage of NFS (and
> > traditional UNIX's inability to handle pathnames during IO).
>
> I don't want to belabor the point, but I think you're questioning
> the sanity not just of NFS, but also of AFS and CIFS. They
> all use a filehandle or "fid" of some kind to identify a file
> on the server.
Indeed.
> Why is insane ?
Because of the "stale filehandle" issue.
Note that I don't think it is bad to use a "transaction handle": a
filesystem that has a concept of leases on files (which both AFS and CIFS
have), obviously need such a handle anyway to keep track of the lease. And
such a transaction handle will obviously also specify which file in
question we have, and thus it would be silly to send both a pathname and a
transaction handle in a request.
Such a transaction handle also protects against the horrible confusion
generated by concurrent accesses by multiple clients: the server knows who
accesses the file, and can revoce access etc gracefully, so that you never
get truly confused.
But any filesystem that is stateless like NFS, or where leases expire
(like everybody else) should definitely at least have the ability to
re-send the whole pathname from the client when re-activating the lease,
instead of using that silly notion of a "file handle" that can expire and
generate the whole notion of "stale filehandle".
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.
That said, pathnames are _hard_ to maintain in a traditional UNIX
environment. I understand completely why people like filehandles etc. It
simplifies the UNIX client a lot (and the traditional unix server too, if
the server is truly unix-based and it uses a regular "inode number" kind
of format).
But while it may be the simple approach, it is definitely not a good
design. We could have had much simpler filesystems without state if we
just used a pathname. Somewhat like SMB (which is a bad filesystem too,
but for _other_ reasons ;)
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 : Mon May 15 2000 - 21:00:26 EST