Re: Unionmount. Basic details

[Carl Fredrik Hammar]

Hi!

On Tue, Apr 07, 2009 at 12:20:40AM +0300, Sergiu Ivanov wrote:
> > Then it might be possible to implement the shadow node in unionmount
> > and pass it to unionfs.  Just wrap a file descriptor around the port
> > and let unionfs inherit it, to make unionfs use it pass `/dev/fd/$FD'
> > as an argument.
> >
> > If you're uncomfortable keeping around a process just to implement
> > a shadow node, consider implementing a dedicated shadow node server.
> > That just sitts on e.g. `/server/shadow' and passes out shadow nodes in
> > responce to RPCs of a new kind.
> >
> > I think such a server might be a good idea in any case.  Shadow nodes are
> > already needed by nsmux (right?) and seem generally useful for creating
> > ``anonymous'' file systems.  The only real question is wheather they
> > are independant enough to be put in their own server.
> 
> Yep, I'm really uncomfortable about keeping around processes, but in
> this case I'm inclined to think that spawning an extra process would be
> an overkill. I'm more inclined to the simpler variant of borrowing the
> code from unionfs, stripping off the unnecessary features and modifying
> the startup sequence to get a new translator.

Well it isn't simpler in the sense that we'd need to maintain two very
similar yet different code bases.  Improvements to one would likely get
ported to the other.

> 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.

I don't think there would be any extra context switches, they would
just be divided between different processes.  An extra process per mount
is no big deal IMHO.

> You see, I suppose that some time later we will be adding some specific
> merging rules, which would be very difficult (if not impossible)
> with the approach you are suggesting (about reusing unionfs as a whole).

OK, here we have a more concrete reason to fork unionfs's code.  However,
I can't think of any rules that wouldn't also be useful in unionfs.
Have you got anything in particular in mind?

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.

> I like the idea of a shadow-node server :-) 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.  ;-)

Regards,
  Fredrik