(1) Are dentry pointers safe and effective as nfs filehandles, and
(2) Given the above, are the dentry use counts tracked correctly?
With regards to (1), the problem I see is that dentry pointers are drawn
from a small memory pool and will not be unique even within a very short
timeframe. The nfsd server has to remain stateless, so it doesn't hold
the dentry use count for very long, and once released the dentry pointer
may quickly be reused.
The subsequent revalidation depends on the parent pointer, name length,
and name hash to establish identity, but these factors together don't
ensure uniqueness -- one parent directory may be used for many files,
file name lengths tend to fall in a narrow range, and the dentry hash is
designed for reasonable lookup efficiency, not for establishing
uniqueness in a large namespace.
>From the above considerations it seems likely to me that a reused dentry
could be mistakenly validated as a different file, with confusing or
disastrous results. Such failures would occur sporadically and
non-repeatably, and would be difficult to distinguish from genuine nfsd
bugs.
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 filehandle is presented by a client, the dentry would be looked up in
the table and a dget() added for that use. Dentries could be expired
after some period (e.g. 10 minutes or whatever) so that the server would
remain asymptotically stateless, and after a dentry has been expired any
subsequent reference would fail, as the id codes would be unique.
Regards,
Bill