Date: Tue, 29 Apr 1997 21:09:47 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Gary Palmer <gpalmer@freefall.FreeBSD.ORG> Cc: David Greenman <dg@root.com>, Don Lewis <Don.Lewis@tsc.tdk.com>, fs@FreeBSD.org Subject: Re: the namei cache... Message-ID: <Pine.SV4.3.95.970429205108.7361C-100000@parkplace.cet.co.jp> In-Reply-To: <6949.862284052@orion.webspan.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Apr 1997, Gary Palmer wrote: > > 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. > > I don't think any form of non-hashed search will work well with this: > > root@news:/var/spool/news/misc/jobs/offered> ls | wc -l > 20040 > > or the /var/spool/news/control/cancel directory, which typically has > hundreds of thousands of files in it (unless the admin is smart and > sets the expire on control.cancel to 0, which will bring it down to a > max of about 50,000) Poul's analysis regarding stale entries seems to make sense though, there would be an increase in the hit rate if we could efficiently move stale entries to the head of the LRU list or lists. It'd be nice to be able to keep the hash around while solving this problem too though. I'm going to try the Poul's patches in a week or so. I just doing WorldStone on RELENG_2_2, it's not incredibly scientific but it's a nightly cron job anyway and RELENG_2_2 isn't changing very much so you can get somewhat of a controlled environment. Regards, Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.970429205108.7361C-100000>