[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) |
Hi,
> > 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.
unionmount.
Regards,
Fredrik
- Re: Unionmount. Basic details, (continued)
Re: Unionmount. Basic details, olafBuddenhagen, 2009/04/09
Re: Unionmount. Basic details, olafBuddenhagen, 2009/04/26
Re: Unionmount. Basic details, Sergiu Ivanov, 2009/04/10
Re: Unionmount. Basic details, olafBuddenhagen, 2009/04/26
Re: Unionmount. Basic details, olafBuddenhagen, 2009/04/09
Re: Unionmount. Basic details, Sergiu Ivanov, 2009/04/26