lkml.org 
[lkml]   [1997]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Msdos name alias patch for 2.1.48
Date
From
>I've been thinking along a slightly different line.
>
>What could be done is that "lookup" will just match any of the canonical
>names, but when it notices that it has matched the same inode twice, it
>just throws away the new dentry and returns the old dentry instead. That
>way only one dentry would ever be active at a time.
>
>Note that this would mean that the directory cache would only cache _one_
>version of the name, and anything else goes through lookup, but I guess
>that is reasonable. It would also imply that a filesystem that cannot have
>name aliases would have _zero_ overhead, because none of this would be
>seen at the VFS layer at all.
>
>Note that name aliases are reasonably easy to detect: the dcache already
>keeps a circular list of alias dentries for each inode (used for
>hard-linking, but there is nothing to say that a low-level filesystem
>couldn't use it for this too).

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

\
 
 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2011 Jasper Spaans