> > I decided I would try to handle the problem with aliases by not putting
> > any dentries in the dcache for filenames that are aliases or for filenames
> > that haven't been found. This way, there would only be one dentry per
> > directory and file.
>
> Any reason for not treating the short aliases as hard links?
> Let's see: You would have hard links to directories, then, but I
> think the dcache can handle this.
> Also, you might want to delete other d_entries when you delete
> an inode. This is tricky, as we don't have a list of all dentries
> for a given inode. But see below.
If you implement it there could be another very useful use for this code:
open_by_inode() for the kernel nfs server. Just create a temporary name
somewhere in the same filesystem as the inode and treat it as 'virtual'
(only existing in the dcache) hardlink. Then the NFS server can just
use this dentry to manipulate the file without ever knowing the real
filename. This would cleanup the current mess (Sorry Bill) that is used
currently to lookup a NFS fd.
I wrote a open_by_inode() function that works this way,
a openi() syscall I implemented for testing seems to work fine. I didn't
integrate it in the NFS server yet.
-Andi