Right (although I don't think any current filesystem truncate names any
more: minixfs _used_ to do it, but it leads to various nasty problems for
standard UNIX utilities, so it's generally better to just disallow them).
> A better approach might perhaps be if xxx_lookup not only
> creates the dentry for the original name, but also for a `canonical' name,
> ie., the name it would return in xxx_readdir.
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).
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?
Linus