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

On Tue, Mar 23, 2004 at 09:04:52AM +0900, YAMAMOTO Takashi wrote:
> > > currently, when you do "rm somefileonnfs",
> > > our nfs client always issues a LOOKUP rpc before a REMOVE rpc even if
> > > the "somefileonnfs" is on the namecache.  it's what i'd like to chang=
e.
> > >=20
> > > as i said in the first mail, it could be achieved in nfs code.
> > > however, i think that it's cleaner to push what i called ufs-ism into
> > > ufs-like filesystems themselves.
> >=20
> > You missed my point. You have skipped from "step A" to "step E" of your
> > thought process. I wanted you to work through the steps. Mainly since I
> > _think_ that at "step C" we can do things differently, and make both you
> > and me happy. However since you aren't stepping through things, it's ha=
rd
> > to tell.
>=20
> i don't see what's unclear, sorry.
> i described the problem and the code is there.

The problem is that there is a lot between the problem (local vs remote=20
file system desired cache behavior) and the code. By making the=20
progression from problem to code one step, you muddle a lot of things=20
together. My objection has been to one part of your changes (now that I=20
understand them better), however when your changes are presented as=20
all-or-nothing, that means I object to your changes. That doesn't seem to=
=20
help the idea of getting the important part of the change (local vs remote=
=20
caching) in.

> > The part of your change I object to the most is your change to=20
> > vfs_lookup.c. From reading the comments, the code to disable caching in=
=20
> > the delete case is exactly correct, and the not-CREATE case seems ok=20
> > (though perhaps a bit questionable). docache's definition is, after all=
,=20
> > /* =3D=3D 0 do not cache last component */.
>=20
> > Thoughts?
>=20
> you believe the comment while i believe the code when they disagree.

Be careful. You're making assumptions about what I believe and don't
believe that I don't see how you can back up.

I believe how I think things should work. In this case, the comment agrees
with that belief.

> i'd say the comments are wrong, however, ok, i have no particular problem
> with your suggested way.  (ie. change the MAKEENTRY's behaviour)

Thank you. Also put something in there somewhere about what we should do=20
about negaitve caching & DELETE or RENAME for the remote fs case. I'd=20
suggest turning the cnp->cn_nameiop !=3D CREATE into cnp->cn_nameiop =3D=3D=
=20
LOOKUP, but the point's still up for discussion if you want something=20
else.

Take care,

Bill

--bajzpZikUji1w+G9
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAX4dDWz+3JHUci9cRAswSAJ91Q1LjDhw4yZD+zcK6x8LBJZro9wCeJ+NM
b8pAAjWVxNuyDRtpEpwNmyI=
=1VYO
-----END PGP SIGNATURE-----

--bajzpZikUji1w+G9--