> > I think a much safer scheme would be for nfsd to issue a unique,
> > non-repeating id code for each dentry, and to save the dentries (with
> > the use count held) in a hash table for some amount of time. Each time
>
> A conventional BSD nfs daemon uses the inode of the file and some versioning
> information for the NFS file handle state. The inode is a good thing to
> keep handy. It means if people open a file and work with it then a rename
> from another client has unix semantics. A path hash doesnt have this property
> and is very slow to resolve
I think Bill's scheme of keeping a hash table FileHandle -> dentry
does this too. It doesn't care about renames when the hash tables is always
properly updated. In this scheme dentry is just "unique structure to
describe the file" (like an inode), the NFS fast path doesn't care
about the actual filenames.
-Andi (who likes the idea, and hopes that someone will implement it)