Subject: Re: LK_SHARED for VFS_VGET/FHTOVP
To: YAMAMOTO Takashi <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 05/26/2004 20:28:54
Content-Type: text/plain; charset=us-ascii
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?
> > Both the interface and our file system implementations.
> if you think that our filesystem implementations are mpsafe without biglo=
> 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=
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=
are there at all in the networking code?
> > > documented where?
> > sys/kern/vnode_if.src. Yes, it does not explicitly state that locked st=
> > =3D=3D exclusive, however until Chuck's change nothing used shared lock=
> > before that it'd have seemed like stating the obvious.
> 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=
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.
> > 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.
> because VOP_LOCK/UNLOCK !=3D lockmgr.
Actually it is. struct lock *v_vnlock is a pointer to a lockmgr lock, and=
neither the new snapshotting code nor layered file systems will work if=20
> or, do you want to use VOP_LOCK(vp, LK_RELEASE)? :-)
Yeah, I agree that that's silly. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----