That's correct. The unfsd file handle looks like this:
4 bytes hash of (inode, dev)
1 byte n = length of path starting at /
n bytes 8bit hash of (inode, dev) of pathname component
rest padded with 0 bytes
While this file handle is invariant across system reboots, it has other
problems. Probably the worst is that it is not invariant against renames.
Try this on an NFS-mounted partition:
mkdir zappa
(mv zappa/frank .; echo "You lose") > zappa/frank
and you should get 'stale file handle', or, on 2.0.30, an empty file.
(I guess there's a problem with error propagation in the flush-on-close
stuff in NFS). This problem also affects the dentry-stuff file handle
layout, BTW.
The second problem is of course performance. When presented with a file
handle that's not in its internal cache, unfsd has to reconstruct the
file path from the handle. The algorithm goes something like this:
Start with directory /. Do a readdir, check the 8bit hash of each component
against the corresponding byte in the file handle. If it matches, descend
into directory. If directory exhausted, back up one level. If we found
a directory that matches the entire hash path in the file handle, look
for an entry whose 32bit hash matches that given in the file handle.
I think it doesn't need explaining why we wouldn't want such a thing in
the kernel nfsd.
Another problem is that unfsd uses a file handle cache at all. I don't
recall what the exact size is, but regardless how large you make it,
for any real work it will always be too small and start thrashing. Combine
that with the above algorithm and you quickly start wondering why people
don't complain about it any louder than they currently are.
Basically, the _only_ way to do NFS correctly is to put dev/inode number
into the file handle and use them to retrieve the inode/dentry/whatever.
This is the way Sun's implementation works, and this is what the NFS spec
reflects. Read it, and you'll find that there's really no other way to
do it on a Unix box if you want to be 100% compliant.
Olaf
-- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax okir@caldera.de +-------------------- Why Not?! -----------------------