Subject: Re: RFC: VOP_LOOKUP() speedup
To: Bill Studenmund <wrstuden@netbsd.org>
From: Reinoud Zandijk <reinoud@netbsd.org>
List: tech-kern
Date: 05/05/2004 00:47:47
Dera Bill,

On Tue, May 04, 2004 at 12:13:28PM -0700, Bill Studenmund wrote:
> On Tue, May 04, 2004 at 01:07:10AM +0200, Reinoud Zandijk wrote:
> > 1) before a VOP_CREATE() / VOP_MKDIR() / ... is called, VOP_LOOKUP() is 
> >    called first to check if the file opr directory name is allready present 
> >    or not.
> > 2) VOP_LOOKLUP() uses the namecache to check if its there...
> > 3) if the namecache fails, VOP_LOOKUP() needs to search the directory from 
> >    disc for the name. _hopefully_ its still in the cache....

So this is correct? i dont miss out a thing?

> > 1) every vnode/inode describing a directory gets a `number of directory
> > entries in cache' counter.
> > 
> > 2) on addition or removal of an entry from the cache, this number is 
> > maintained. Also when an entry is purged from the LRU.

i've implemented this part in my test-kernel on my Alpha, and it works 
fine.

> > 3) with this provision, ,VOP_LOOKUP() now can check the number of directory
> > entries in the directory with the `number of directory entries in cache'
> > and see that the answer of the namecache is authorative if the two are the
> > same.

Only filing systems that want to use this feature need explicit coding; 
othres just ignore and go for the normal way.

> However, I think you can do everything you want in your own file system.

:)

> All you need is one extra bit per node. When you do a linear search of the 
> dir, create vnodes and name cache entries for all files. Then flag the dir 
> as all-present. Then in vop_revoke, in addition to blowing away cache 
> entries, clear the "All present" bit in the parent vnode.

but wouldn't this give a `false hit' when say a file is deleted? since the 
VOP_REVOKE() will be called after the VOP_REMOVE()?

> One thing you might need is a way to search the name cache for all parent 
> vnodes of a given vnode. Not sure if we have this interface. If we don't, 
> it'd be a fine thing to add to the general code. Then on revoke, you clear 
> the bit in all present parents.

I dont get this honestly; if one focuses on the namecache itself and let it
handle the counters itself, then the filingsystem doesn't need to search 
around etc. and is the definition of the reference count allways correct.

i'll try out a patch on msdosfs to see how it performs.

Cheers and take care too,
Reinoud