--BOmey7/79ja+7F5w
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 27, 2004 at 11:02:30AM +0900, YAMAMOTO Takashi wrote:
> > > what's "the vnode system"?
> > > the vnode interface itsself, or eachfilesystem implementation,
> > > or something else?
> >=20
> > Both the interface and our file system implementations.
>=20
> if you think that our filesystem implementations are mpsafe without biglo=
ck
> because of LK_EXCLUSIVE, i have to say that you're too optimistic. :-)

I agree that I'm being optimistic. However the vnode code has fine-grained=
=20
locks and uses them extensively. Other kernel systems don't have fine-=20
grained locking at all, thus we are farther along. I mean, how many locks=
=20
are there at all in the networking code?

> > > documented where?
> >=20
> > sys/kern/vnode_if.src. Yes, it does not explicitly state that locked st=
ate=20
> > =3D=3D exclusive, however until Chuck's change nothing used shared lock=
s. So=20
> > before that it'd have seemed like stating the obvious.
>=20
> it says that VOP_GETATTR doesn't require the vnode locked.
> (i think it's fine.)
> so updating atime in VOP_READ should be protected by some
> filesystem internal locks anyway if you want to see a consistent view of
> timestamps without biglock. (a spinlock is enough)
> afaik, there's no problem which was introduced by LK_SHARED for VOP_READ.

Huh? VOP_GETATTR()? I agree VOP_GETATTR() doesn't have a problem. But it'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.

I agree that's the direction we want to go, we just aren't there yet.

> > > i think it's bad idea to allow to use arbitrary fancy lockmgr flags
> > > for VOP_LOCK.
> >=20
> > Why? At one point I'd have agreed with you. At this point, however, I
> > think we "know" that we have lockmgr locks. We might as well use lockmgr
> > to our benefit. Hmm... need to look at unionfs to see if it's happy with
> > shared locks and downgrade.
>=20
> because VOP_LOCK/UNLOCK !=3D lockmgr.

Actually it is. struct lock *v_vnlock is a pointer to a lockmgr lock, and=
=20
neither the new snapshotting code nor layered file systems will work if=20
it's not.

> or, do you want to use VOP_LOCK(vp, LK_RELEASE)? :-)

Yeah, I agree that that's silly. :-)

Take care,

Bill

--BOmey7/79ja+7F5w
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAtWB2Wz+3JHUci9cRAp1kAKCY3qUTe4Ae6PZ/hzX+9oLS2llUewCfXsna
26Ft0UvNXfbHWrDWDA9PXx8=
=Tfri
-----END PGP SIGNATURE-----

--BOmey7/79ja+7F5w--