Re: Unionmount. Basic details

[olafBuddenhagen]

Hi,

On Thu, Apr 09, 2009 at 10:09:04PM +0200, Carl Fredrik Hammar wrote:
> On Wed, Apr 08, 2009 at 07:10:26PM +0200, olafBuddenhagen@gmx.net
> wrote:

> > 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...
> 
> Why stop at two?  Mounting several file systems at once seems
> perfectly reasonable to me.

I do not see much point in mounting several file systems at the same
time. Just mount them one after the other. This is less efficient of
course (as you get a whole stack of unionmount translators), but
probably not very common anyways...

> > 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...
> 
> Seems like a potential use case for libmob.  We have discussed similar
> use cases, but I must admit that I haven't considered a generalized
> ``hosting service'' for mobile objects.

Indeed, while writing this, I realized that this *might* be a genuine
second use case for the mobility framework... But as I mentioned
elsewhere, my ideas on this are still extremely vague, so I can't really
tell.

> > 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 :-)
> > )
> 
> Bootstrapping a unionmount of nsmux like might be tricky.  ;-)

Why would you want to union mount nsmux? Seems rather pointless.

> My first thoughts of anonymous file systems got me thinking of an
> ``anonfs'' translator that launched translators encoded in the paths.
> But the thought of encoding paths in a path gave me shudders.

Isn't that more or less what nsmux does?...

> Then it got me thinking of a shell utility, e.g.:
> 
>    letfs foo "/hurd/nsmux foo" -- ... -- \ settrans /hurd/unionfs foo
>    %1 %2 ... %n
> 
> Where %i is replaced with /dev/fd/${fd to %i's root}.

I don't really get the idea...

Anyways, what I want is basically a way to launch a translator as part
of another command which is using it -- a bit like traditional UNIX
pipes. I think nsmux can cover many of the use cases; though it probably
would get rather icky for the more complicated ones... Some more generic
anonymous translator mechanism could be useful -- but I have no clue how
it would work exactly.

> This leaves the question of how and when to make the anonymous file
> systems go away.

This is actually quite easy for anonymous translators: They can go away
as soon as all clients have closed the connection (and any outstanding
processing is finished) -- as it is anonymous, nobody other than the
initial client should be able to connect to it, so we know it won't be
needed afterwards. In this regard too it is very similar to programs
connected with anonymous pipes...

Deciding when a translator should go away is much more tricky for normal
static translators -- we don't know whether they will be still needed
after all previous clients closed the connection.

-antrik-