Subject: mnt_leaf, v_vnlock, VLAYER
To: None <firstname.lastname@example.org>
From: YAMAMOTO Takashi <email@example.com>
Date: 11/30/2005 07:35:24
[ 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 filesystems, tho.
> > (mnt_leaf, v_vnlock, VLAYER, etc.)
> Well, what else should we do? I agree that I don't really like the
> mnt_leaf idea.
> v_vnlock is partially an optimization, partly a convenience, and partly a
> tool to enforce more-rigid locking. It's an optimization because it means
> we can play with locking w/o traversing a call stack. It's a convenience
> because for the most part, layers have simple locking needs and I think
> it's fine for them to use the same lock structure as the leaf node. It's
> an enforcement tool to make everyone think more about locking and follow
> it. I do not believe the latter reason is as strong a motivator as it was
> when I initially added it. It also forces (or can, depending on the
> developer :-) ) the idea of thinking of a stack of vnodes as both a
> collection of individual vnodes and as a cloud of vnodes.
> The snapshotting code ended up using v_vnlock in a manner that I hadn't
> expected, but which really seems reasonable (at first I disliked it, but
> now, while I find it a bit weird, it seems fine).
> VLAYER was mainly added to be informational, but it mutated. Now, it is
> used in many of the same places as VALIASED, for mostly the same reason.
> That reason is that we have a form of aliasing going on, and we need to
> 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 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.
> Take care,
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 unionfs
as well before making this kind of optimazations. (or give up and
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.
IMO, vnode locks currently protect too many different things:
1. vnode's identity (ie. vgone/revoke)
2. lookup, its side effects, and dirops.
separating #1 is on my to-create-a-branch list.