From owner-freebsd-fs Thu Apr 24 20:09:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA19924 for fs-outgoing; Thu, 24 Apr 1997 20:09:06 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA19916 for ; Thu, 24 Apr 1997 20:09:04 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id DAA16880; Fri, 25 Apr 1997 03:08:45 GMT Date: Fri, 25 Apr 1997 12:08:45 +0900 (JST) From: Michael Hancock To: David Greenman cc: Don Lewis , fs@freebsd.org Subject: Re: the namei cache... In-Reply-To: <199704250052.RAA12150@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 24 Apr 1997, David Greenman wrote: > >This is right from the source: > > > > cnp->cn_hash = 0; > > for (cp = cnp->cn_nameptr; *cp != 0 && *cp != '/'; cp++) > > cnp->cn_hash += (unsigned char)*cp; > > cnp->cn_namelen = cp - cnp->cn_nameptr; > > > >It sure looks to me like it stops on '/' ;-) > > > >Also, even if you totally ditch the hash, you still need the loop > >to find the end of the component. > > Good point, although I guess you could always waste a "null" longword at > the end and trigger on that. Hmmm. An improved hash looks like low hanging fruit that's worth trying. Regarding the name list of the vnode approach, it might be interesting try phk's patches and see how it works out with something like WorldStone. The approach to the name cache / vnode cache coherency problem he's trying to solve makes sense logically. However, addressing the performance needs of news servers or large /var/mail directories might lead to a lot of complications. It's like you need some kind of dynamic hash table creation capability for each directory vnode. I don't think this is practical. Regards, Mike