Subject: Re: vn_lock(LK_RETRY) (was: Re: CVS commit: src/sys/miscfs)
To: Chris Jepeway <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 06/21/2004 17:20:15
Content-Type: text/plain; charset=us-ascii
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=
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.
> > 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----