[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unionmount. Basic details

From: Carl Fredrik Hammar
Subject: Re: Unionmount. Basic details
Date: Thu, 9 Apr 2009 20:08:58 +0200
User-agent: Mutt/1.5.18 (2008-05-17)


> > unionmount is expected to merge the filesystem on which it sits with
> > the filesystem exposed by the translator it is asked to start in
> > unionmount mode (further referred to as ``the Translator'').
> Nah, I think there are various clearer ways to name it: e.g. "target
> translator", or perhaps "inferior" (like in a debugger), or "mountee"...
> :-)

My vote is on ``mountee'', as you might of noticed in my other mail.

> I don't think we should call it "shadow node": although there are some
> similarities, it seems to me that it's not quite the same as the shadow
> nodes in nsmux -- it would be confusing.
> For now, I suggest calling it "internal node" or "hidden node". We can
> still change the name later when the exact role becomes clearer.

How about ``wedge node''?  I like the image it gives of prying apart the
mountee from the mount point.  :-)

I'll stick to ``shadow node'' until a decision is made.

> It is not fully clear right now -- I realized that there is another
> decision to make: should the unionmount translator be directly visible
> as the translator attached to the mount node; or should it serve as a
> proxy, forwarding all requests on the filesystem port to the target
> translator -- thus making itself more or less transparent, so it appears
> as if the target was attached to the mount node directly?
> I tend towards the latter.

I think the latter makes a lot more sense.  I can't think of any reason
to let the mountee be aware that it's detached from the underlying
file system.  If anything it would just confuse it.

> One question is, how does the user request the unioning functionality? A
> possible way would be adding options to the actual translators -- but
> this would probably have to be handled explicitely by each translator,
> making it rather ugly.
> Adding an option to settrans seems a more logical approach. However, we
> will need a way to pass this information to the translator somehow -- it
> might require changes to the translator startup procedure...

I'd go with a settrans switch or a new but similar command, i.e.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]