Re: dcache questions

[Linus Torvalds]

On Tue, 30 Dec 1997, Gordon Chaffee wrote:
> 
>  >  - make the filesystem-specific hashing and name comparing functions
>  >    compare the two names as equal - so that only one dentry exists for
>  >    both of them.  This is the "real" fix, but depending on how the name
>  >    mangling works it may not be all that easy. 
> 
> Name mangling is such that for any given long filename, you can end up
> with a random alias.  In general, you don't, but you can't count on the
> alias having anything to do with the long filename.

Right ho...

Anyway, I'm not totally opposed to supporting "dcache aliases" through
re-instating the dcache pointer (and circular list) in the inode. We used
to do that in the first few releases of the new dcache because the dache
had some major problems that required it - partly because the interface to
the low-level filesystems hadn't been cleaned up to know about the
dentries.

I removed the inode->dentry backpointer because everything that used it
back then used it for the wrong reason, and removing it was the only way I
could think of to _force_ people to not mis-use the list. It turned out to
be a good judgement call, and the VFS layer and the low-level filesystems
are better for it: it forced us to make the VFS layer cleaner.

HOWEVER, there have always been some nagging small things that have made
me suspect that we do want to have the inode->dentry mapping possibility
for certain uses. The problems with knfsd have made me 99% sure that we do
want to re-instate the mapping again (so that knfsd can use dcache aliases
internally), and the VFAT kind of horrid name aliases might be another
valid use of such a beast. 

Anyway, I just wanted to tell people that I didn't remove the
inode->dentry list because I disliked the concept, but because I disliked
the code that used it. So, Gordon, if you decide that it would help your
job enourmously, then I just wanted to let you know that I won't fight the
issue..

		Linus