>> Well, the NFS protocol allows that [see rfc1813, p. 21: "If two file handles from >> the same server are equal, they must refer to the same file, but if they are not >> equal, no conclusions can be drawn."] >> >Interesting. That does seem to break the method of st_dev/st_ino for finding >hardlinks. For Linux fileservers I think we generally do have 1:1 correspondence >so that's not generally an issue. > >If we're getting into changing specs, though, I think it would be better to >change it to enforce a 1:1 filehandle to inode correspondence rather than making >new NFS ops. That does mean you can't use the filehandle for carrying other >info, but it seems like there ought to be better mechanisms for that.
The filehandle is very much the appropriate mechanism for that. A handle is opaque. The client has no business doing anything with it besides sending it back to the server. Though you seem to want to avoid adding new NFS operations, what you're proposing is changing the nature of existing ones so that new operations would have to be added to get back what the existing ones do! If it's important to know that two names refer to the same file in a remote filesystem, I don't see any way around adding a new concept of file identifier to the protocol. BTW, a primary characteristic of an "identifier" is that it can be used to tell whether you've got the object you're looking for, but often can't be used to _find_ that object. For the latter, you need an address. There lots of examples where you can't practically use the same value for both an identifier and an address. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
