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

On Tue, Apr 06, 2004 at 07:39:41PM +0900, YAMAMOTO Takashi wrote:
> hi,
>=20
> > I think the reason for doing the removal is that you simplify the cache
> > logic.
>=20
> actually, its side effects increases complexity, IMO.

While I can see advantages to the current code,I am not particularly=20
wedded to this behavior. I'll look at changing it.

> > You don't need to remember to remove the negative entry before=20
> > creating the positive one, and if the opertation fails such that you kn=
ow=20
> > you have no such file, you can (if you wish) freely create a new negati=
ve=20
> > entry.
>=20
> i think it's better to allow cache_enter() to overwrite an existing entry.
>=20
> > And, I think, the changes I posted only do the removal for the=20
> > CREATE case, not the DELETE case. I decided to let the fs deal with tha=
t=20
> > case. :-)
>=20
> why do you always want to do the automatic removal for CREATE case?
> consider O_EXCL create on nfsv2.
> if you already have a negative cache entry,
> i guess you don't want to issue a remote call to recheck it.
> (or, at least, want to let the filesystem implementation make
> its decision about usefulness of the cache.)
> because current cache_lookup() silently removes the entry,
> you have no clean way to see the negative entry.

As above, I'm not that wedded to the entry removal for CREATE.

Take care,

Bill

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

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

iD8DBQFActk6Wz+3JHUci9cRAh5HAJwLOVTETsEU8UxkiHlai1goXPG2KQCfS4UY
oYKDpXoZyEW7Ou7Y10qP7Ko=
=tIb6
-----END PGP SIGNATURE-----

--a8Wt8u1KmwUX3Y2C--