Subject: Re: The buffer cache and directory blocks
To: Thor Lancelot Simon <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 01/09/2004 17:19:17
Content-Type: text/plain; charset=us-ascii
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----