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

On Wed, Nov 30, 2005 at 07:35:24AM +0900, YAMAMOTO Takashi wrote:
> [ moved from a private list, thus this long citation ]
>=20
> > On Tue, Nov 29, 2005 at 03:51:12AM +0900, YAMAMOTO Takashi wrote:
> > > i personally hate these "partial solutions" around layered filesystem=
s, tho.
> > > (mnt_leaf, v_vnlock, VLAYER, etc.)
> >=20
> > Well, what else should we do? I agree that I don't really like the=20
> > mnt_leaf idea.
> >=20
> > v_vnlock is partially an optimization, partly a convenience, and partly=
 a
> > tool to enforce more-rigid locking. It's an optimization because it mea=
ns

[snip]

> > If we were to revisit v_vnlock and VLAYER, I think we could also address
> > VALIASED at the same time. The common issue is that we have multiple
> > vnodes refering to the same underlying thing, and we sometimes need to
> > take actions that apply to the cloud of vnodes rather than just one (and
> > the inheritance chain between a specific vnode and the appropriate leaf
> > vnode).  We now have three different subsystems, devices with VALIASED,
> > layered vnodes with VLAYER, and snapshot vnodes, doing about the same
> > thing. It may be time to rethink.
> >=20
> > If we do this revisit, we may also want to look into some of the issues
> > that Jason and I have affectionately refered to as VOP_UPCALL() issues.=
 =20
> > The idea is that sometimes we need to pass information or a request UP =
the
> > vnode stack, through all its branches. The biggest points I recall about
> > this are we need a way to get a good use count of references outside of
> > the vnode cloud (so that close() and such do the right thing) and
> > VOP_REMOVE() processing should trigger fast reclamation if possible.
> >=20
> > Take care,
> >=20
> > Bill
>=20
> in general, a layered filesystem shouldn't need any special treatments
> from upper layer, as far as it's implemented as a filesystem.
>=20
> i hate them because they only solve very simple cases.
> IMO we should find a solution which can handle complicated ones like unio=
nfs
> as well before making this kind of optimazations.  (or give up and
> drop unionfs.)
> sorry, i don't have such a good solution on hand.  it's a reason why
> i haven't removed them yet. :-)  i guess that simplifing vnode locks is
> a good first step.

Ha! :-)

Yes, changing how we do locking is probably a good thing to do.

> IMO, vnode locks currently protect too many different things:
> 	1. vnode's identity  (ie. vgone/revoke)

If we do this, we remove one use of VLAYER, in vget(). The problem now is=
=20
that vget was written with the assumption that vnodes on the free list are=
=20
unlocked. For layered ones, that's not necessarily true.

> 	2. lookup, its side effects, and dirops.

I'd like to do this one, but I'm not sure if I'll have time before you get=
=20
to it. :-)

> 	3. read/write

My thought here is to map them, internally, to range locks. Thus=20
non-overlapping writes can proceed, as can reads.

> 	4. etc?
> separating #1 is on my to-create-a-branch list.

Sounds good.

Take care,

Bill

--MAH+hnPXVZWQ5cD/
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDjPFHWz+3JHUci9cRAky7AJsEP+bHlCtfmILshH/2vLWJxAzPeACfYfGf
AAAnIUn0qeETte6LKz1oqfk=
=pSpy
-----END PGP SIGNATURE-----

--MAH+hnPXVZWQ5cD/--