Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 06 May 1997 09:39:39 +0200
From:      Poul-Henning Kamp <phk@dk.tfs.com>
To:        Terry Lambert <terry@lambert.org>
Cc:        current@FreeBSD.ORG
Subject:   Re: DOC: NAME CACHE USAGE 
Message-ID:  <2940.862904379@critter>
In-Reply-To: Your message of "Mon, 05 May 1997 13:59:15 PDT." <199705052059.NAA16562@phaeton.artisoft.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <199705052059.NAA16562@phaeton.artisoft.com>, Terry Lambert writes:
>With all of Poul's puttering around in the name cache code (I still
>think the cache data should be a pointer into the directory vnode
>page where the actual name is, instead of making a copy of the name
>in another buffer, considering the directory vnode must be in core
>for there to be a cache reference, especially after his changes), I
>thought it would be the right time to post this.

This would waste storage for two reasons:

     1. The size of the namecache structure is 36 bytes, which means that 
     we can tack another 28 bytes onto the malloc allocation for free.
     This covers most of the names we ever see.

     2. Copying the name away means that the directory vnodes doesn't have
     to have any pages cached to be useful.  Think of a heavily used 
     directory "/usr/local/lib/this/weird/path" With your suggestion we
     would have to have at least a page for each of the 5 directories
     for the namecache to work.

>This is a document that I made prepatory to doing some work to move
>the cache lookup and entry out of the FS specific code and into common
>code, so that you wouldn't even have to make VOP calls if you got
>cache hits.  This design offers the bonus of making the FS code itself
>smaller for each FS, and by making the code more bullet proof by making
>the usage entirely uniform across all FS's.

This is a nice idea, but not well thought out.

If you were to do that, you would rob the filesystems of the control
they have today to expire cached data at this time, leaving filesystems
like union, nfs and null no other option than disabling cacheing entirely.

>I haven't really been
>able to pursue this work because it's all I can do to track current
>and repair conflicts on my existing changes  8-(.

	(chorus)
	How nice the world would be,
	How perfect the world would be,
	If you all would listen more to me!

:-)

>It should also provide some usage information to Poul so that he can
>better direct his efforts to optimize common cases.

I think even Terry has misunderstood what "optimizing the namecache"
means.  I'll leave it as an excercise to the reader :-)


Poul-Henning

PS: there are a number of errors in your table.  For instance 
cache_purge is called by vgone(), which covers many more cases 
than you document.  Please don't post wrong information.

--
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?2940.862904379>