--UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 21, 2004 at 02:38:52PM +0900, YAMAMOTO Takashi wrote:
> hi,
>=20
> > That's different, and that's my objection. Before your change, we will
> > look in the name cache even if we're about to rename or delete. So if t=
he
> > node's known, we find it fast.
>=20
> actually, cache_lookup() doesn't return the cached entry
> if MAKEENTRY is not set.  and ufs code depends on this behaviour.
> it's what i called ufs-ism.

Well, given that you have patches to every other file system, it does not=
=20
seem at ALL ufs-centric. Thus "ufs-ism" is not appropriate.

> > After your change we will always blow the
> > cache entry away and then do a to-disk lookup.
>=20
> it's how our lookup(9) and vnode ops works *currently*.
> ufs needs it, but nfs doesn't.

While I agree you are correct that that's how the code works now (it is=20
quite twisty in places), it is not at all clear to me that ufs "needs" it.=
=20
It could just be that ufs was coded to behave this way. Given that the=20
fact the cache entry removal code dates from revision 1.1 of vfs_cache.c,=
=20
we'd need to look at the Berkeley revision histories to see why the code=20
is as it is. Also, given that disk is going to get slower and slower with=
=20
time (relative to CPUs), I'm more interested in having all of the file=20
systems use the cache.

Let's start over. What exactly are you trying to do? You said something
about NFS doing inefficient lookups. Ok, how is the current code causing=20
that? Let's look at all the different way's to get that.

Take care,

Bill

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

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

iD8DBQFAXilKWz+3JHUci9cRAkvkAJ9s+3qpbK7ZEPKiukrH9PeZSKhY8wCeK4l7
gymK3SFgVDDCbYMZEF6pPDc=
=zgmU
-----END PGP SIGNATURE-----

--UlVJffcvxoiEqYs2--