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

On Mon, Jun 21, 2004 at 07:02:26PM -0400, Chris Jepeway wrote:
> >VOP_LOCK() and friends are not advisory.
> OK.  A reading of the Red Daemon book led me
> to believe otherwise.  I realize that's
> no longer a definitive source for NetBSD workings.
> I mention it as the original BSD VFS/VOP design,
> where the idea seems to be that VOP_LOCK() is merely a
> hint to a file system that "hey, if you actually lock
> something now, I'll guarantee consistent access to your
> vnodes and you won't need to do any extra work."  I thought
> all along, though, that any file system that felt up
> to it could do that extra work if it wanted.

I've never seen that in practice. All the file systems I've ever seen (in=
=20
NetBSD) that didn't do anything with VOP_LOCK() did NOTHING for locking.

Note also that layered file systems were much more an experimental thing=20
in 4.4BSD. The ones we got never really worked unil I bashed on them=20
around the 1.4/1.5 time frame.

One of the steps I took to make them work well was to get stubborn about=20
locking, and make stuff start doing real locking.

> >While what you describe would be fine if we had only leaf file=20
> >systems, it
> >won't work for layered file systems.
> Aha.
> >  They are implemented assuming that
> >VOP_LOCK() and friends actually work.
> Am I following you, here?  You're saying the implementation of the
> layered, stackable file systems like nullfs require that
> all leaf file systems implement VOP_LOCK()?  Err...sorry, not
> "the implementation of layered f/s requires" but rather "the API for
> implementing layered f/s requires?"

The implementation requires it. Actually the current layered file system=20
implementation includes a shadow locking feature, which would work even=20
if the lower fs didn't do VOP_LOCK(). However, I think it's time to rip=20
that out, as all the leaf file systems support real locking. And it's a=20
waste to have real locks shadowing other real locks.

The main thing is, whatever our locking scheme, we should be consistent=20
about it.

Take care,

Bill

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

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

iD8DBQFA13s/Wz+3JHUci9cRAguQAJwP85sb+6Ow2E8weBxECDjrW0PB7wCcC9qm
lpYnMPSBu+bnS1LTZbbD6cM=
=c1MI
-----END PGP SIGNATURE-----

--WfZ7S8PLGjBY9Voh--