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

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=
e I=20
> > spoke about how we almost have stopped using it. :-)
>=20
> 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=
=20
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
backwards.

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=
=20
from them. However I'm not sure if it's really worth all the churn that=20
would imply.

> > The place I care most is in handling PDIRUNLOCKED, especially in error
> > cases. The code is correct there, so I'm happy. :-)
>=20
> i think that you want to add checks at "goto bad" path in lookup().

Hmmm.. You're right. Thanks.

Take care,

Bill

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

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

iD8DBQFA1j9fWz+3JHUci9cRAmAKAJ9+oxFFA9/2oFuRkOMK0ttHVt+7xgCdG4Cj
EFT/yPKxGPn6cjJb+GjY1ac=
=dPph
-----END PGP SIGNATURE-----

--eheScQNz3K90DVRs--