Subject: Re: vn_lock(LK_RETRY) (was: Re: CVS commit: src/sys/miscfs)
To: YAMAMOTO Takashi <>
From: Bill Studenmund <>
List: tech-kern
Date: 06/20/2004 19:13:40
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 21, 2004 at 11:01:18AM +0900, YAMAMOTO Takashi wrote:
> > > i don't think genfs_nolock is bad at all.
> >=20
> > ?? Faking locking is good?
> it's good in some cases because
> it allows filesystems to choose its own locking strategy.

I disagree. Whatever our locking methodology is, we should follow it. I=20
only see genfs_nolock() as useful in the kernel of the developer who is=20
transitioning our code to an "internal" locking methodology.

I don't think a file system can really choose to do something other than=20
our "real" locking method. That strikes me as being like changing which=20
side of the road vehicles drive on, and starting with just the trucks.

> > 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=
> > done in the file system. I'm sure there probably is something we can le=
> > from them. However I'm not sure if it's really worth all the churn that=
> > would imply.
> i meant, "vnode lock removal =3D=3D transition to fs-internal locking".
> sorry for confusing.

Oh, ok. No problem.

Take care,


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

Version: GnuPG v1.2.3 (NetBSD)