Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Jan 95 17:47:44 MST
From:      terry@cs.weber.edu (Terry Lambert)
To:        wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman)
Cc:        roberto@blaise.ibp.fr, jkh@freefall.cdrom.com, hackers@freefall.cdrom.com
Subject:   Re: Optimizing CVS?
Message-ID:  <9502010047.AA00456@cs.weber.edu>
In-Reply-To: <9501312358.AA18319@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jan 31, 95 06:58:48 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> <<On Tue, 31 Jan 95 14:31:28 MST, terry@cs.weber.edu (Terry Lambert) said:
> 
> > Finally, the inode cache needs to be moved over to a vnode cache instead,
> > and generalized at the comsumer level for the file system (ie: moved the
> > hell out of UFS).  SVR4 actually has this one right with their DNLC
> > mechanism, although they (incorrectly) do not allow for use of the DNLC
> > as a negative hit cache.
> 
> Gee, this sure looks like a vnode cache to me...
> 
> /*
>  * Look for a the name in the cache. We don't do this
>  * if the segment name is long, simply so the cache can avoid
>  * holding long names (which would either waste space, or
>  * add greatly to the complexity).
>  *
>  * Lookup is called with ni_dvp pointing to the directory to search,
>  * ni_ptr pointing to the name of the entry being sought, ni_namelen
>  * tells the length of the name, and ni_hash contains a hash of
>  * the name. If the lookup succeeds, the vnode is returned in ni_vp
>  * and a status of -1 is returned. If the lookup determines that
>  * the name does not exist (negative cacheing), a status of ENOENT
>  * is returned. If the lookup fails, a status of zero is returned.
>  */
> int
> cache_lookup(dvp, vpp, cnp)
>         struct vnode *dvp;
>         struct vnode **vpp;
>         struct componentname *cnp;

You're right... but some questions, please:

Is it called in the vncalls layer or in UFS for the hits?

Can I cache a vpp of NULL?

Can I cache a vpp of (struct vnode *)-1 or some other magic cookie to
indicate a negative hit?

Can I flush the cache of a particular vp to support multiple name spaces
for, oh, say, a Linux style umsdos?

Can I flush the cache of all vp's for a given dvp?

Is the code that handles returns in the lookup in the FS or is it in the
vncalls layer?

Is the code that handles cache hits capable of distinguishing between a
NULL (not present in cache) and the magic cookie (not present in directory)?

Is a cache entry considered a hold (open instance) as far as the vnode is
concerned?


If the answer to all these questions (and more that I have pruned from
this list) isn't "YES!", then it needs work (note: it needs work).


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502010047.AA00456>