On Wed, 2 Jun 1999, Konrad Schroder wrote:

> On Wed, 2 Jun 1999, Bill Studenmund wrote:
> 
> > Whenever a vnode gets stacked on top of another node, it locks the
> > simple_lock in the underlying node, and then inserts itself in the list.
> > When it gets reclaimed, it (locks the underlying simple_lock and) removes
> > itself.
> 
> Yes :^)  This kind of registration is what I was trying to get at with my
> earlier message about watchdogs.  But:
> 
> > The second half is what the underlying node does with this. I think the
> > best thing is that vclean would look at the list on the vnode it is
> > cleaning, and repeatedly call vclean on the head vnode. Then it would
> > vclean the given node. Oh, it would have to release the interlock first.
> 
> What about unionfs?  Would not the appropriate thing to do there be to
> cause the upper vnode to switch its lower vnode to the appropriate vnode
> in the other filesystem, rather than to cause the upper vnode to be
> cleaned out and discarded?

I don't think so. The state of things on-disk haven't changed due to this
cleaning, so I don't see why unionfs should be changing vnode locations.
If the r/w node disapears, then any recent change disapear. Silently
(since any open file wouldn't notice). The only case where it would make
sense to keep going might be in the case of a vnode existing in both
layers, and the r/o node dies. But since the only way this will occur
(vcleaning a live node) is if we're forcably unmounting an fs. I'm not
sure if it's a bad thing to loose the node in that case. :-)

In the cleaning case, I think the best option is to just clean all the
upper nodes.

> If so, we are saying that the behavior should be dependent on the
> upper-mounted filesystem; should we not call a vop on the upper vnode,
> rather than always calling vclean?

I've thought about that, but as I thought the best thing to do is just
tear it all down, vcleaning them all seemed best. :-)

> I think, too, that this registration could provide the facility for a more
> general operation, a sort of reverse bypass that calls the an
> above-mounted layer instead of a below-mounted layer; which could be
> useful for other things as well.  Ordinary filesystems should not need to
> know about it, but rather, layered filesystems would be able to take
> indirect vops on the vnodes that they reference, as well as direct vops on
> their own vnodes.  This could make a watchdogfs work, say; or provide
> better synchronization between layers if it ever becomes useful to cache
> data at an upper layer.

I think data caching would be handled with getpages() & putpages(), the
details of which I'm not familiar with. But I'm not sure if this is the
solution to that problem - in that case the data are being cached in only
one place at a time - this list will contain ALL upper vnodes. Thus the
caching part will need to know where the data are, and get them back.

I'm not really sure what from-below VOPs make sense. :-)

Take care,

Bill