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

On Thu, May 27, 2004 at 12:46:25PM +0900, YAMAMOTO Takashi wrote:
> >=20
> > Huh? VOP_GETATTR()? I agree VOP_GETATTR() doesn't have a problem. But i=
t's=20
> > not the one I have issue with, VOP_UPDATE(), which is documented to=20
> > require a locked vnode. That's an LK_EXCLUSIVE lock. So at present we=
=20
> > don't have any fs-internal locking.
>=20
> i thought that we're talking about ITIMES.
> (you mentioned about biglock and i said "atime-update".)

We are. VOP_UPDATE() is how ffs_read() pushes the atime-update,=20
specifically in the IO_SYNC case.

> i don't see why VOP_UPDATE is related to biglock.
> can you be more descriptive?

VOP_UPDATE is related to all of this in that it is modifying data. It is
doing things it needs a writer lock for. Is that clearer?

> > > because VOP_LOCK/UNLOCK !=3D lockmgr.
> >=20
> > Actually it is. struct lock *v_vnlock is a pointer to a lockmgr lock, a=
nd=20
> > neither the new snapshotting code nor layered file systems will work if=
=20
> > it's not.
>=20
> then i'd like to say it's a bug in them.

Well, you can say it's a bug. But in both cases, multiple vnodes (of in-
principle different file systems) need to be able to use the same lock.=20
Things don't work right otherwise. Also, by using the same lock, things=20
are more efficient.

> anyway it's better to (try to) keep VOP_LOCK and lockmgr different, IMO.

Why?

If we ever decide to change, we either go with something that takes the
same flags (and thus isn't really a change), or we have to change all the
flags. A big fat eid session (as in pkgsrc/devel/id-utils) will get a lot
of it.

I mean if we ever go with a different lock system, we will need the same=20
set of lock features, so changing lock systems will be simply changing the=
=20
flags we pass in and changing the few actual lockmgr calls.

Take care,

Bill

--Qo8f1a4rgWw9S/zY
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAtXH5Wz+3JHUci9cRAqrTAKCYNbAt5Gk3BvANtnS9r4dXc3wBwwCgh9x4
UmjKQVNIleeWEOvk8Z02mOg=
=bzFU
-----END PGP SIGNATURE-----

--Qo8f1a4rgWw9S/zY--