Date: 	Mon, 15 May 2000 11:53:34 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Proposal: int (permission*)(struct dentry *, int)
Newsgroups: fa.linux.kernel

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 revoke 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

Date: 	Mon, 15 May 2000 13:01:54 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Proposal: int (permission*)(struct dentry *, int)
Newsgroups: fa.linux.kernel

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