Subject: Re: vn_lock(LK_RETRY) (was: Re: CVS commit: src/sys/miscfs)
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 06/20/2004 18:52:31
Content-Type: text/plain; charset=us-ascii
On Mon, Jun 21, 2004 at 09:32:45AM +0900, YAMAMOTO Takashi wrote:
> > I agree that file systems using genfs_nolock is bad. Thus the note wher=
> > spoke about how we almost have stopped using it. :-)
> it seems that you misunderstand what i tried to say.
> what i meant is, "nfsd relies on filesystems having real vnode locking.
> it should be changed, IMO."
Why? This comment I really don't understand. How is it a bug to rely on=20
"real" vnode locking?
> i don't think genfs_nolock is bad at all.
?? Faking locking is good?
> generally, i think that vnode locks should go away.
> (and i know you disagree. however, don't worry.
> i have no plan to propose such a change in near future. :-)
I freely admit that our current locking scheme has warts, and would like=20
to change it to remove them (the warts).
However I don't see what we will gain by _removing_ locking. Fine-grained=
locking is the direction we want to go for SMP, so removing locking from=20
the one system that does it in any sort of fine-grained manner seems=20
Changing how we do locking, however, I can see. I also know that other
OSs, like Solaris, don't do the external locking we do; all the locking is
done in the file system. I'm sure there probably is something we can learn=
from them. However I'm not sure if it's really worth all the churn that=20
> > The place I care most is in handling PDIRUNLOCKED, especially in error
> > cases. The code is correct there, so I'm happy. :-)
> i think that you want to add checks at "goto bad" path in lookup().
Hmmm.. You're right. Thanks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----