Re: Unionmount. Basic details

[olafBuddenhagen]

Hi,

On Mon, Apr 06, 2009 at 06:58:23PM +0200, Carl Fredrik Hammar wrote:
> On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:

> So the only difference between unionmount and unionfs is the setup and
> the shadow node, right?

Well, not quite. unionmount needs additional functionality for the
internal node and related stuff; but on the other hand, the actual
merging (unioning) requirements are simpler: while unionfs must be able
to handle an arbitrary number of merged locations, for unionmount it's
always exactly two. This simplifies the implementation and policy
decisions, and might even call for different optimization approaches --
so it seems quite possible that the code base will diverge considerably
after the fork...

Of course it can be argued whether this is really desirable :-)

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

While there are some servers in the current Hurd that work like that, I
don't think this is a good approach. We really want to move away from
such centralization -- it limits scalability, lowers robustness, and
increases complexity...

If we really feel the need to run several instances of a translator in a
single process (to reduce overhead), this should happen as transparently
as possible, and probably be handled by a generic framework -- similar
to translator stacking...

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

As I pointed out in the other mail, the requirements here are really
different from the shadow nodes in nsmux. Yet the observation about
anonymous file systems is extremely to the point!

I actually realized a couple of days ago that unionmount could probably
be done by a combination of nsmux and unionfs: I think it should be
possible to do something like

   settrans veth /hurd/unionfs veth veth,,eth-multiplexer

(I didn't want to bring this up yet, to avoid further confusion :-) )

The funny thing is that while I was thinking about something like
anonymous file systems multiple times in the past; and also had a vague
realization that nsmux can serve most (if not all) use cases for that;
and even was aware that this is what the example above uses -- somehow I
never really consciously thought about the "anonymous" aspect as the
common underlying idea up till now...

> The only real question is wheather they are independant enough to be
> put in their own server.

Indeed, while we always try to think of the shadow nodes as separate
translators, they are really quite intertwined with the rest of nsmux.
But perhaps with anonymous translators as a more generic concept, the
separation would be clearer...

However, it's probably a safer approach to duplicate the code in
unionmount for now; and only once it works, and we know exactly what the
requirements are, we should try to factor out the common
functionality...

-antrik-

PS. Sorry I didn't answer the mobility mail yet... Was too busy with
GSoC preparations, and some silliness in the offline world. I hope I'll
get around to it next week or so...