[ 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 
> cope.
> 
> 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,
> 
> 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 unionfs
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.

IMO, vnode locks currently protect too many different things:
	1. vnode's identity  (ie. vgone/revoke)
	2. lookup, its side effects, and dirops.
	3. read/write
	4. etc?
separating #1 is on my to-create-a-branch list.

YAMAMOTO Takashi