Subject: Re: mnt_leaf, v_vnlock, VLAYER
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 11/29/2005 16:24:39
Content-Type: text/plain; charset=us-ascii
On Wed, Nov 30, 2005 at 07:35:24AM +0900, YAMAMOTO Takashi wrote:
> [ moved from a private list, thus this long citation ]
> > On Tue, Nov 29, 2005 at 03:51:12AM +0900, YAMAMOTO Takashi wrote:
> > > i personally hate these "partial solutions" around layered filesystem=
> > > (mnt_leaf, v_vnlock, VLAYER, etc.)
> > Well, what else should we do? I agree that I don't really like the=20
> > mnt_leaf idea.
> > v_vnlock is partially an optimization, partly a convenience, and partly=
> > tool to enforce more-rigid locking. It's an optimization because it mea=
> > 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.
> > 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.=
> > The idea is that sometimes we need to pass information or a request UP =
> > 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.
> > Take care,
> > Bill
> in general, a layered filesystem shouldn't need any special treatments
> from upper layer, as far as it's implemented as a filesystem.
> i hate them because they only solve very simple cases.
> IMO we should find a solution which can handle complicated ones like unio=
> 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.
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=
that vget was written with the assumption that vnodes on the free list are=
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=
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----