--M9NhX3UHpAaciwkO
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=
ory
> 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
>=20
> Darren Jewell suggests that a possible problem arises when entries from t=
he
> same directory block are read in sequentially; if the block does not rema=
in=20
> 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=
=20
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).
>=20
> 2) Track whether all directory entries in a given block have been read
>    in.  If so, explicitly move the block to the AGE list.
>=20
> Both approaches seem somewhat complex.  Comments?

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

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE//1MVWz+3JHUci9cRAlyCAJ9swm87o63MBHEpHojwu604Hr1GgACdHgPH
jA8iLhUyIcApDSrdSvBfQSk=
=30vr
-----END PGP SIGNATURE-----

--M9NhX3UHpAaciwkO--