Re: Unionmount. Basic details

[olafBuddenhagen]

Hi,

On Sat, May 02, 2009 at 08:16:32PM +0200, Carl Fredrik Hammar wrote:
> On Sun, Apr 26, 2009 at 06:28:51AM +0200, olafBuddenhagen@gmx.net
> wrote:
> > On Thu, Apr 09, 2009 at 10:09:04PM +0200, Carl Fredrik Hammar wrote:

> > 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...
> 
> It's easier to manipulate a single translator than a stack.

I don't agree with this statement in general -- on the contrary.
However,

> Consider the case of unioning three file systems.  To remove the
> middle one you'd have to unmount the two top ones and then remount the
> top.

You have a point here.

I wonder whether other systems implementing VFS-based union mounts allow
for this...

> I was thinking of more of a /anonfs directory to create anonymous file
> systems, e.g. `/anonfs/unionfs foo bar/baz'.

Interesting idea.

> But would get ugly if foo or bar contained `/'.

Well, it would be no problem as long as the file name is only ever
parsed by the anonfs handler... As soon as something else parses it
first, it could result in strange effects.

> > > 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}.
[...]
> It would launch a number of translators, passing file descriptors to
> their roots to a command where variables are expanded to paths
> specifying these file descriptors using glibc's /dev/fd functionality.
> In my example, translators are separated by `--', each having settrans
> like syntax (not sure why I put quotes in there), and after the last
> `--' comes the command with replacement variables.

I see.

> > > 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.
> 
> Well, yes.  But all current translators assume that they are static
> and thus doesn't go away when there are no connections (though some do
> timeout eventually).  Extending all translators to also support this
> is not a good option IMHO.

I think it is the *right* option. I often found the current approach --
each translator defining a fixed, arbitrary timeout -- to be
questionable, in various contexts. I think we have to replace it by
something more useful.

Perhaps the timeout should be user-defined, e.g. as a parameter to
settrans...

> A third option might be to continually ask it to go away until it
> does.

Nice idea :-) Until we have some proper mechanism to specify the
timeout, this might do as a workaround well enough...

-antrik-