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

On Tue, Mar 23, 2004 at 09:04:53AM +0900, YAMAMOTO Takashi wrote:
> > We'd need to change the nami cache interface some for this. AFAICT=20
> > cache_lookup() doesn't actually return the cache entry, it just returns=
=20
> > ENOENT. To do what you're suggesting (which I think is good), we'd need=
 to=20
> > add a way for a file system to hang data off of the cache entry, so tha=
t=20
> > nfs can time out the entry.
> >=20
> > As a simpler step, we could just adjust cache_lookup() so that it only=
=20
> > uses the negative cache entry for LOOKUPs, not !=3D CREATE. As long as=
=20
> > rename and delete ops have MAKEENTRY off and we remove the entry if=20
> > MAKEENTRY isn't there, we never hit this code path, so the two conditio=
ns=20
> > (=3D=3D LOOKUP, !=3D CREATE) are the same.
>=20
> nfs code already checks validity of negative caches by
> checking the directory's ctime.  do you mean it isn't enough?

The nfs code actually makes a stat RPC each time? That seems inefficient.=
=20
Well, that sounds fine for LOOKUP.

For RENAME or DELETE, it might be faster to just ignore the negative cache=
=20
and try the RPC. It would depend on which is faster, the lookup on the=20
server or the extra RPC. If the server itself is doing negative caching,=20
overall it's probably better to just do the RPC.

Take care,

Bill

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

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

iD8DBQFAX4yAWz+3JHUci9cRAkhcAKCZcXICtnUAGZvVzlasMIizzh3hSwCfVsSw
3AsFh6VHJP9JY8FJaZs4+Ss=
=yrjY
-----END PGP SIGNATURE-----

--qFgkTsE6LiHkLPZw--