In SunOS, the dnlc did a hold on the inode. So the last thing
holding the inode from being flushed was frequently the dnlc. This
was a bummer for NFS since NFS servers didn't look things up via
pathnames (probably what we should have done is used the dnlc for
both pathnames and filehandles and we would have been fine).
Aside from NFS, this worked great. You tuned the dnlc to do what
you want and it had the side effect of keeping the pages in the
cache. Having the inode w/o the pages is frequently a lose and
having the pages without the inode makes no sense.
Thoughts?
It is funny you mention this, because Olaf Kirch has just found a way
to use our generic VFS dnlc _as is_ for NFS. (when you forcefully
invalidate an nfs inode, you bump it's version number, when you do the
dnlc lookup you check if the dnlc version number matches the inode
one, if not this is a negative hit, you do a real server request and
refill the negative hit with the servers response which refreshed your
inode information)
In any event, currently the inodes are detatched from the dnlc, just
the information necessary to pick a match via a string hash, and the
stuff necessary to do an inode hash lookup with the dnlc response, is
in there. This is more light weight and perhaps faster, I sort of
prefer it this way.
I think if you stick inodes directly into the dnlc you risk two
problems:
1) inode thrashing, you need to be extremely careful here, because
you must age your LRU based upon two things, dnlc hits and inode
hits (via iget()'s) I have no idea if a sensible aging scheme can
be made to work with this
2) you are growing the inode free list more often, if lookups lead
to a reference in the dcache and it hangs out in there, and you
get flooded with a bunch of iget()'s you just keep growing the
inode pool, things subside and you are left with all these
excess inodes
It certainly needs more thought, I am probably going to setup some
statistic/profiling mechanism into the dcache and inode manager to see
what I can learn about all this.
---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><