> Hello Bill,
>
> > 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.
>
> I had the impression that unfsd maintained a table of sent file
> handles and a pointer to the actual file. The problem with this
> approach is that clients complain if the server crashes or resets. Is
> this what you are thinking to do, or are you providing a way to go
> from the inode number to the file?
AFAIK the unfsd uses a hash over the inode numbers of every pathname
component. When it can't find the filehandle in it's internal caches
it has to walk the directory tree to find the path again. That was done
because there is no way to open by inode in userspace (basically the same
problem that knfsd is facing currently. But in-kernel it can be fixed ,)
For more information see Olaf Kirch's Paper from LinuxExpo (olaf.ps).
It explains the issues and the architecture of knfsd very well. Don't know
if it's still online, www.linuxexpo.org seems to be down.
-Andi