From owner-freebsd-hackers Tue Jan 31 16:53:51 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA15474 for hackers-outgoing; Tue, 31 Jan 1995 16:53:51 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA15468; Tue, 31 Jan 1995 16:53:49 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA00456; Tue, 31 Jan 95 17:47:45 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502010047.AA00456@cs.weber.edu> Subject: Re: Optimizing CVS? To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Date: Tue, 31 Jan 95 17:47:44 MST Cc: roberto@blaise.ibp.fr, jkh@freefall.cdrom.com, hackers@freefall.cdrom.com In-Reply-To: <9501312358.AA18319@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jan 31, 95 06:58:48 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > < > > 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.