The validation problem can be reduced to "given this filehandle, what
dentry represents the file?" I approach this by trying several stages
of validation based on various caches. The filehandle itself currently
includes dentry and parent pointers, hash and length, inode and parent
inode numbers, and the xino and xdev values. (This won't fit on 64 bit
machines, so will have to be changed later.)
Step 1 is a search of a short-term cache in which dentries are held with
the use count. Dentries are added to this cache from fh_put instead of
being dputted. Only non-negative dentries are added, and for the lookup
to succeed the dentry pointer and inode numbers must match. When an
entry is kicked out of this cache to make space, the parent dentry is
added to a dir cache, and the name string is added to a name cache along
with inode and parent inode numbers.
Step 2 is the current d_validate() routine, with an added check that the
dentry's inode must match the inode number in the filehandle.
If step 2 fails, the next step is to reconstruct the dentry from a cache
of names and inode numbers. Since names are added to this cache whenever
an entry is kicked out of the stage-1 cache, it should usually have the
name.
The final step (which I haven't added yet) is to use the full
inode-number-based lookup the same way unfsd does. This will be much
more time-consuming, but my hope is that with suitable design of the
first three stages, this will only rarely be called.
My plan is to get this working well enough to release some patches for
testing, so that we can start tracking down other problems in knfsd. If
anyone has some ideas for improvement, or some problems that I've
overlooked, please post your comments and suggestions.
Regards,
Bill