> > If dentries are doomed to fail, then it would be good to
> > just admit it. There is no shame in reverting to inodes.
> > The dentries are a great idea, but perhaps better suited
> > for a non-POSIX system.
> > So, what do the VFS hackers think? Can dentries work?
> > Would throwing them out be harder at this point?
> I think that dentries should stay, but I also think NFS
> should go instead :-)
NFS should definately go! =) Dentries are good too - we just haven't gone
far enough yet to extract the benefits; this would mean cutting inodes
even further out of the picture. The main benefit over the inode-centric
view of things is that it becomes possible to support non-posix
filesystems much more easily. Knfsd just plain isn't worthwhile in a
non-inode centric system - the two are mutually exclusive (imho).
> Other *nixes use a dcache of sorts (SCO does), so I don't
> see it as being a concept problem. It looks like it's an
> implementation problem.
In my re-reading of 2.0 code a few days ago, I think I see why the dcache
had such horrible performance: ext2 performs actions that invalidate the
dcache for a directory (incrementing i_version) when it needn't do so. Eg:
ext2_create - it updates i_version, but then immediately does a
dcache_add. Am I mistaken in my belief that i_version is meant to act as
a version for the 'use' of the inode, rather than a version of its data?
That is, i_version should be incremented when and inode goes out of use
and is subsequently re-used for something else. (relating back to nfs)
> >From here on in is complete jibberish...
>
> I think the problems with the present dcache stems from it
> being the master of all inodes. Instead, it should be a
> slave to them.
Maybe, but maybe not. The old dcache had the nice property of not
requiring the inode in RAM to maintain the cache. How will this affect
low memory systems? I'm really curious about the overall effect of
dentries on performance. Hmmm --- how might a 'fixed' 2.0 dcache compare?
-ben