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

On Tue, Jun 22, 2004 at 10:46:28AM +0900, YAMAMOTO Takashi wrote:
> > > > and 2) it destroys our ability=20
> > > > to use v_vnlock. v_vnlock makes life much nicer for layered file sy=
stems,=20
> > > > as it lets us readily access one lock for a stack of vnodes.
> > >=20
> > > i think that it's better to remove v_vnlock because:
> > > - it's only useful in the limited cases.
> >=20
> > Let's see. Layered file systems and snapshots. They both make good use =
of=20
> > v_vnlock.
>=20
> layered filesystems can use it only when it uses 1:1 vnode mapping and
> the underlying filesystem uses lockmgr to implement vnode lock and
> the lock is exported.  it's very limited.

Every file system except unionfs is limited?

> > > - it involves complexity in layered filesystems
> > >   as they should deal with two cases. (exported and not exported)
> >=20
> > The exported case is the greatly prefered one. The only case where it=
=20
> > isn't used will be unionfs. And if I could figure out a way to have=20
> > lockmgr() calls do the locking unionfs needs, I'd do that instead. :-)
>=20
> IMO, locking should be left to each filesystem implementations.
> it's a bad idea to force everybody to use the same one.
> (esp. when it's lockmgr. :-)

We used to do that. We then had each file system doing almost the exact=20
same thing. We did not like that situation. So we made everything use=20
lockmgr(), and life was better. The file system locking was much more=20
maintainable, and we gained a fair bit of functionality.

So while we may decide to do something other than lockmgr(), going to it=20
gained us a lot.

> > > - it violates VOP abstraction.
> > >   sharing a lock can be achieved using locking VOPs.
> >=20
> > It can, but the latter's slow,
>=20
> but it's clean.

Yes, and microkernels are "clean." Abstractions are good, but only when=20
they really gain you something.

I guess another part of my experience with this is that I made dmfs, the=20
data migration file system. In it, the ability to directly & quickly=20
change lock state was very useful.

> > and can blow the kernel stack. With just=20
> > one or two layers, it doesn't make that much difference. But with some =
of=20
> > the multi-layer ideas Heidemann had, we can get may more layers.
>=20
> locking VOPs are not likely the most stack-consuming VOPs.
> cheating only for them doesn't make much sense.

I don't look at it as a cheat. I look at it as a requirement that file=20
systems do real, hard-core locking. And given the state of things when I=20
started, that was a very good thing.

> > Also, I like Heidemann's idea of the collection of vnodes (the leaf one=
=20
> > and the ones over it) acting as an aggregate object. One object, one lo=
ck,=20
> > v_vnlock points to it.
> >=20
> > I admit that v_vnlock is only a partial implementation of what Heideman=
n=20
> > describes. A more complete one, which worked well for unionfs, would be=
=20
> > interesting.
>=20
> where can i read "what Heidemann describes"?

That would be his disseration.=20
http://www.isi.edu/~johnh/PAPERS/Heidemann95a.html

Take care,

Bill

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

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

iD8DBQFA17rsWz+3JHUci9cRAlWNAJ0YrpuAFmNH6WBILfgVezyrjpmJ4wCcC/Ju
Y6IIyGnBtU1RqhOLo5JsEoY=
=qDr6
-----END PGP SIGNATURE-----

--lteA1dqeVaWQ9QQl--