In message <010e01c177f6$72840780$0100a8c0@snowdrop>"David Laight" writes

>Yes - I didn't quite say what I meant....

Ah. Thanks for clarifying that.


[snip nfs basics]

>For NFS V1 (I think it's V1) the NFS spec defines the length of the
>file handle, the number of ways the above information can be stashed
>in the available space is limited...

V2. (V1 hardly ever saw the light of day; the Suns i used went from
"nd" to nfsv2).

Point is, someone suggested, in essence, grab *just* the "inode
number" (or moral equivalent) out of the NFS file-handle, and hash
that".  But RFC1094 says that file handles are opaque, 32-bit
quantities. But there are several distinct NFS V2 implementations.
Those different implementations put their "inode" data in different
locations within the opaque 32-byte field.

And there is *no reliable way* for NFS clients to ascertain which
particular NFS implementation an NFS server is using, or whereabouts
the server stashes the "inode number".

tcpdump tries hard to guess, in order to print opaque file handles
symbolically. It very frequenty gets it wrong. There's no known way to
do better than tcpdump does; and its not good enough.

Sorry for being longwinded. Jason (and others) have already said this,
but not quite clearly enough, it seems.

>Clearly the only 'important' piece here for hashing purposes is the
>inode number from the underlying filesystem.  

Yes, but in general, you *cannot tell* whereabouts in the 32-byte
opaque object that data resides.  You could guess wrong, and end up
hashing on bits with little-to-no entropy at all: worse off than now.
So you have to hash the entire file handle. Trying to hash ``just the
inode number'' -- as suggested -- doesn't work, not in NFS v2.