Re: Unionmount. Basic details

[olafBuddenhagen]

Hi,

On Thu, Apr 09, 2009 at 07:29:27PM +0200, Carl Fredrik Hammar wrote:
> On Tue, Apr 07, 2009 at 12:20:40AM +0300, Sergiu Ivanov wrote:

> > This would yield faster code (no extra context switch, the shadow
> > node is within the main translator) and more control over the
> > merging functionality.
> 
> Isn't the shadow node used mostly by the mountee?  If so it will be
> used through RPCs in any case.

The mountee talks to the internal node via RPCs of course. However, as
there seems to be consensus that unionmount should be transparent, so
that it appears as if the mountee sits on the underlying node directly,
the internal node has to serve as a proxy between the underlying node
and the mountee: when the mountee wants to talk to the underlying node,
the internal node has to forward it; when some external process does
requests on the unionmount node, they have to be forwarded to the
mountee by the internal node.

Actual file name lookups on the unionmount node on the other hand are
not forwarded to the mountee directly, but rather are handled by the
merging code first. That means that if the merging functionality and the
internal node implementation do not share a process, either one or the
other type of RPCs needs to be forwarded from the part implementing the
unionmount node to the other part.

It's not the overhead that bothers me most though:

> > However, I would rather keep shadow-nodes inside processes, because
> > they are cheap as compared to RPCs and you have full control over
> > them. Moreover, some translators (like unionfs and hence unionmount)
> > would like to keep a list of nodes they own and drop nodes when they
> > don't need them. This policy would require more effort if a
> > shadow-node server is involved.
> 
> Does unionmount (or nsmux) need to do anything except keep them around
> and destroy them when not needed anymore?  It seems easy enough to
> destroy a node through RPCs, just unlink it or something.  If not it
> should be easy enough to create a shadow_node_destroy RPC.
> 
> Also unionfs itself should only be interested in the mountee and the
> underlying filesystem, not the shadow nodes (AFAICT).
> 
> Thinking about it, clean-up presents some problems with ditching a
> unionmount process.
> 
> The mountee becomes effectively orphaned when unionfs dies.  With no
> way to reach it from the file system, the user would have look up its
> PID to kill it.
> 
> To handle fsys_goaway requires that there be a proxy for the ports
> that receives it and forwards it to the mountee and, if that doesn't
> fail, forwards it to unionfs.  You probably know, but I'm hoping
> there's only one such port.  In a pinch, this could also be
> implemented by a server shared by all unionmounts.
> 
> Now the question is what to do if unionfs crashes or is killed. If
> there where a unionmount process it could detect it and ask the
> mountee to go away.  Doing without is harder.  The only solution I can
> come up with is letting unionfs inherit a port to a server that kills
> the mountee when there are no send rights to the port.  But that seems
> like a really weird hack.
> 
> Of course, implementing such servers would be a long term goal.  This
> is just to convince you that it's possible to reuse unionfs without an
> additional process per unionmount.  Admittedly, these solutions are
> aren't very pretty, but then again I don't think an extra process per
> unionmount is a problem at all.  ;-)

I must admit that I didn't even try to fully understand all your
points... But it seems quite clear that most of them do not really apply
only to a central implementation of internal nodes, but rather are a
direct result of the internal node implementation being separate from
the rest of unionmount -- whether centralized or not.

I guess you see yourself that this introduces a lot of complexity -- and
complexity is what we want to keep as low as possible, at least in the
initial implementation. This is indeed the reason why we put the idea of
implementing shadow nodes as separate translators from nsmux on ice: We
realized that the necessary interaction would not only increase the
global complexity of nsmux+shadow node, but in fact even the local
complexity of nsmux would probably be of a similar order as with a
monolithic implementation doing all the shadow node handling in nsmux
itself...

The same is probably true here: Trying to reuse unionfs probably creates
more complexity than just forking its functionality.

In a similar vein:

> I'm guessing that it's easier to turn a unionmount that uses unionfs
> to one that uses code from unionfs, then the other way around.  I
> wouldn't start by forking the code-base unless I *knew* that I would
> do it eventually.

On the contrary, I believe it's usually easier to fork something first,
and later re-merge it once you know exactly what you need, than first
trying to generalize the existing stuff, before finally splitting it
up... You don't need to bother about the existing funtionality while
working on the new stuff.

Just a couple of days ago I wrote this blog post:

   http://tri-ceps.blogspot.com/2009/04/plea-for-reinventing-wheel.html

I wasn't actually thinking about this discussion consciously when
writing the post -- but I think parts of it apply here nevertheless.

-antrik-