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

On Tue, Apr 06, 2004 at 11:06:47AM +0900, YAMAMOTO Takashi wrote:
> hi,
>=20
> > I think we have two, remote and local.
>=20
> i think "remove vs local" is too aggressive simplification.
> although i don't argue much about it because anyway i agree our in-tree
> filesystem implementations fall into one of two classes.

Point taken. I agree as we add file systems we may add file systems that=20
need new cache behaviors, and when we do that we may need to revisit this.

> > > > Other than that, what do we need to do? What semantics do we need t=
o add=20
> > > > or change?
> > >=20
> > > don't forget about "CREATE on negative cache" case.
> >=20
> > Ok. Right now, the in-tree cache_lookup() removes a negative entry on t=
he
> > CREATE case.  I think that is the correct behavior. Do you think we nee=
d=20
> > to do something different?
>=20
> cache_lookup() removes entry and returns -1 while
> not all filesystems need non-cached lookup for CREATE.
>=20
> besides, IMHO, updating entries in cache_lookup is just evil.
> it should be occured only when the operation succeed.
> ie. each dirop VOPs should update namecache instead.
> if you feel it as code duplication, i think we can introduce
> cache_update_after_remove, etc. to minimize duplication.

I think the reason for doing the removal is that you simplify the cache
logic. 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 know=
=20
you have no such file, you can (if you wish) freely create a new negative=
=20
entry. 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 that=20
case. :-)

> > > > Put another way, I think we can change our current name cache routi=
nes to=20
> > > > support remote file system semantics in addition to supporting loca=
l file=20
> > > > system semantics. I think these changes will be smaller than the ch=
anges=20
> > > > you just proposed.
> > >=20
> > > how in particular?
> >=20
> > I'll attach a diff. To be honest, it's your initial diff with the one
> > change I wanted made to it. It should fix everything I understand we ha=
ve
> > wrong. What behaviors do you want to change about it?
>=20
> if you're removing a directory entry, and there's a negative namecache
> entry for it, there's no need to do non-cached lookup even for
> ufs and friends.  ie. just returning ENOENT should be fine.

Ok, I'll look into that. Thanks.

Take care,

Bill

--DKU6Jbt7q3WqK7+M
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAchmWWz+3JHUci9cRAtUmAJ953p1OkIkmLv9ClcoNPxt6CTmadQCfR4de
KeVfoi3al321IQiM5n9ZWOo=
=Cxna
-----END PGP SIGNATURE-----

--DKU6Jbt7q3WqK7+M--