Hmmm, this makes sense but it isn't quite what I meant, let me adjust what
I said a bit so it makes more sense. The d_hash element in the dentry
structure is a linked list. I'd suggest adding in hashes for each actual
path looked up, so they would all be hashed (and thus cached), even with
their shortname components; but the all-longname path would be stored in
the dentry's d_name and the parent directory info, etc. would be based on
the "canonical" all-longname path. This means that the dentry would not be
timed out until it stops being accessed by *any* of its paths, but since
the vast majority of the structure is not replicated this should be OK; it
just means you might have some rarely used hashes lingering longer than
they deserve.
This I see as being significantly different from your current method, any
comments? Perhaps the d_hash list isn't intended to be used this way, but
it looks promising. I'd also wonder how the VFAT/NTFS case compares to
hard links, and even symbolic links, which also result in multiple paths
for a given inode. In the case of hard links, there is no way to determine
which one is canonical, so I'd expect they would be two separate dentries
pointing to the same inode.
David
Niemi@tux.org 703-810-5538 Reston, Virginia, USA
"Down that path lies madness. On the other hand, the road to
hell is paved with melting snowballs." -- Larry Wall, 1992