Date: Fri, 25 Apr 1997 08:09:47 +0200 From: Poul-Henning Kamp <phk@dk.tfs.com> To: Bakul Shah <bakul@torrentnet.com> Cc: Poul-Henning Kamp <phk@dk.tfs.com>, hackers@freebsd.org Subject: Re: the namei cache... Message-ID: <2038.861948587@critter> In-Reply-To: Your message of "Fri, 25 Apr 1997 00:53:48 EDT." <199704250453.AAA15841@chai.plexuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199704250453.AAA15841@chai.plexuscom.com>, Bakul Shah writes: >This is analogous to one of the ways one implements a symbol table >in a lexically scoped language processing program. But these programs don't work with a finite bounded number of entries, so reuse policies doesn't matter to them. >Scaling. Directories with 100+ entries are not uncommon. Even >/usr/include and /usr/include/sys have over 100 entries each. You obviously don't know how the name cache operates. Only names you lookup ends up in the cache, it's not the entire directory that gets put into the cache (unless you do a "ls -l" that is). >once encountered a directory with 2,000,000+ entries! One does not >optimize for such border cases but it is nice when they are handled >effortlessly as a byproduct of a design decision. For that case there will be no difference at all, even wcarchive only has 44000 entries in the cache. >A dynamically growing hashtable is a must. Hello Houston ? We have lost gravity! Of course we can't do that in the kernel. Memory is way too expensive. <SOAPBOX> I wish all of these "instant-fs" specialists would read up on their subject matter before they jump in with their misunderstandings! </SOAPBOX> Poul-Henning -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2038.861948587>