Actually, the really tricky part is turning _negative_ aliased dentries
into real ones. Imagine this sequence:
$ cat Xyz
cat: Xyz: No such file or directory
$ touch xyz
$ cat Xyz
cat: Xyz: No such file or directory
The first ls creates a _negative_ dentry called Xyz, which will be
found by the second ls before it hits the filesystem. This is because
there is no alias list for negative dentries, for which there is by
definition no inode.
The other 3 proposals, which are based on having names examined by
the filesystem-specific code _before_ it gets looked up in the cache
avoid this problem.
>So, rough plan:
>
> /* This adds "xyzzy" to the dcache */
>
> ls -l xyzzy
>
> /* This should look up the same dentry, but it will fail
> the dcache test because the name is different */
>
> ls -l XyZZy
>
> /* So what happens in fs/inode.c: lookup() is: */
>
> 'reserved_lookup()' ('.' and '..') obviously fails
> 'dcache_lookup()' fails
> 'real_lookup()'
> - creates a new dentry for 'XyZZy'
> - calls the low-level lookup
> - low-level lookup finds the 'XyZZy' inode
> but notices that it already has a dentry
> by looking at the 'inode->i_dentry' list
> - low-level lookup throws away new 'XyZZy'
> dentry, and instead returns the old
> 'xyzzy' dentry
>
>How does this strike people? The above means that we only ever have one
>dentry for a filename even when you have alias names, and it requires
>almost no changes to the generic VFS layer (it requires a way for the
>low-level lookup to change the dentry, but that should be reasonably
>simple).
>
>The above will obviously not make alias name accesses very efficient: only
>the "first" alias anybody uses will be cached, and all the other ones have
>to be looked up by hand, but is this a major problem in real life?
>
>Comments?
What is the counterpart of making aliased lookups less efficient?
The other 3 proposals have much more efficient aliased lookups, while
having only a tiny impact (probably far less than 1%) on normal
lookups.
> Linus
>
Regards,
Alain