Actually the approach I'm taking now should allow the same degree of
recoverability supported by other servers. Because it's possible that
the dentry pointer in the filehandle will have become invalid (or
represent a different object), I'm also including the inode number and
parent inode number in the fh.
The intent is to do a fast lookup based on the dentry most of the time,
but to be able to fall back to the unfsd-style volume search if
necessary. So to the extent that inode numbers are a reasonably
permanent representation of a file, following a server crash the old
client filehandles could still be looked up, but more slowly.
But of course Linux-based servers aren't going to crash :-)
Regards,
Bill