Subject: Re: The buffer cache and directory blocks
To: Thor Lancelot Simon <>
From: Bill Studenmund <>
List: tech-kern
Date: 01/09/2004 17:19:17
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 09, 2004 at 04:01:10PM -0500, Thor Lancelot Simon wrote:
> I've been thinking about the current use of the buffer cache for directory
> blocks.  It occurs to me that there may be little reason to retain direct=
> blocks in the cache after reading them in, because their contents are also
> cached by the namei cache.  Avoiding this might allow more efficient usage
> of a buffer cache of a given size. =20
> Darren Jewell suggests that a possible problem arises when entries from t=
> same directory block are read in sequentially; if the block does not rema=
> in cache, it will be read in over and over again.  Two approaches seem=20
> possible:

Another problem is what happens when we go to write out atime updates to=20
said nodes? Are we guaranteed that the name cache has enough info (either=
in it or in the vnode) to regenerate the entry?

> 1) Preemptively enter all directory entries from a given block into the
>    namei cache when reading the block in; then put the directory block
>    immediately on the AGE list for priority reuse.  This is vaguely like
>    the ReaddirPlus RPC in NFS (which we do not turn on by default).
> 2) Track whether all directory entries in a given block have been read
>    in.  If so, explicitly move the block to the AGE list.
> Both approaches seem somewhat complex.  Comments?

I think I vaguely prefer (1), assuming it's a non-default thing.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)