On Tue, 25 May 1999, Kevin P. Neal wrote:

> On Mon, May 24, 1999 at 04:12:17PM -0700, Bill Studenmund wrote:
> > Rather than just change the VOP_LOCK protocol to lock bottom up, I'd
> > rather we change the vnode lock interface so that all vnodes point to the
> > relevant struct lock for the node. For stacked fs's, upper vnodes would
> > point to the struct lock for the lower vnode. Thus if we have multiple
> > layers stacked on each other, whenever any one node gets locked, they all
> > are locked.
> 
> What about for fan-in and fan-out?

This proposal is designed to address fan-in, and hopefully won't hose
fan-out. The case of nullfs where users may access the underlying fs in
addition to the nullfs is effectivly fan-in. :-)

> If you have one node up top that fans out to multiple nodes on the bottom
> then where does the lock live? 

It depends on how the fan-out happens. unionfs's present fan-out is like
nullfs's, and won't be hard. i.e. a unionfs vnode is always on top of a
vnode in either the upper or lower layer, never both. So its lock can
point at either the upper or lower vnode's struct lock. In the case where
a node moves from the lower to upper layer (write to the r/o file), the
union/lower lock will be locked (it's a write...) and we will be creating
the node in the upper layer which returns a locked vnode. So switching the
lock pointer will be fine. (*)

> How would you handle, say, a mirroring layer or perhaps a generic 
> (fs-independent) ACL layer?

I don't think the ACL layer would care. It's just a nullfs with more
intrecate permissions verification.

I'm not sure what a mirroring layer would do. I think to support it, we
need to let v_vnlock (the struct lock *) be NULL. That indicates that
stacked layers must call VOP_LOCK & friends on the underlying system.

To help this, I think I want to add layerfs_vnops.c to miscfs/genfs as a
repository of routines for layered fs's. I'll add a layerfs_lock &
layerfs_unlock & layerfs_islocked which would deal with v_vnlock being
null & do a botton-up locking protocol.

> What about cycles in the layering?

What do you mean? Where A is on B is on C is on A? That we don't support.
Or did you mean something else?

Take care,

Bill