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

On Tue, Mar 23, 2004 at 07:58:48AM -0800, Gordon Waidhofer wrote:
> >=20
> > IMHO, eventually, VOP_REMOVE shouldn't take the vnode to be removed at =
all.
> > the directory vnode and the name is enough and each filesystem code can
> > deal with their issues.
>=20
> I agree with this.

I'm not so sure. While I can see how it'd be nice for the file systems,=20
there are other issues that make this not work so well.

> rm a/b/c is currently done VOP_LOOKUP(a), VOP_LOOKUP(b),
> VOP_LOOKUP(c) with lots of modifiers, VOP_REMOVE(c). It should
> be VOP_LOOKUP(a), VOP_LOOKUP(b), VOP_REMOVE(c). The actual directory
> search and cache management should be done below VOP_REMOVE() itself.

Ok, for the sake of arguement, how do you propose we arrange to skip the=20
lookup for "c" in general? Right now, the only code that knows about=20
tearing path names into components is in namei(9), so how do we get the=20
VOP_LOOKUP(c) to be skipped? Also, the right thing needs to happen for "rm=
=20
foo" too.

> File system implementers are compelled to squirrel away hints
> at VOP_LOOKUP(c) time to keep things efficient. VOP_LOOKUP(c),
> VOP_REMOVE(c) may seem natural (for UFS), but is awkward
> in other situations (NFS, my work on OTFS). In the end, I
> had to accept that remove(c) would result in two directory
> searches: one for VOP_LOOKUP(c) and one for VOP_REMOVE(c).

Why did you need another lookup in VOP_REMOVE()? You could have done=20
everything in VOP_LOOKUP(c) and cached it. We also have VOP_ABORTOP()=20
which would let you clean up your cached info.

Also, think about the case where / and /usr are separate file systems.=20
Right now sys_unlink() handles that case. If we push the vnode lookup into=
=20
the file system, they each have to try and get the vnode, to see if=20
there's a file system mounted above it.

> Such a change will probably never be made. I wouldn't
> even advocate such. But it is a VOP design goink worth note.

Well, if it's a good change, we should do it. :-)

Take care,

Bill

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

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

iD8DBQFAYN03Wz+3JHUci9cRAqWvAJwMHcqUGr61iLiG3YoKhkzjA6M5sgCgke21
KNqKEfVUyPhpeVETQ3d9h6Q=
=aGcv
-----END PGP SIGNATURE-----

--Nq2Wo0NMKNjxTN9z--