[Top][All Lists]

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

Re: Unionmount. Basic details

From: Sergiu Ivanov
Subject: Re: Unionmount. Basic details
Date: Wed, 8 Apr 2009 20:17:30 +0300


Carl Fredrik Hammar <hammy.lite@gmail.com> writes:
> On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:
>> I would like to start a discussion about some basic details
>> implementation of the unionmount project.
>> Firstly, the implementation was suggested in two ways: as a stand-alone
>> translator and as a series of extensions to lib{net,disk}fs
>> libraries. [...]
> I think the first approach is the better of the two.  However, you
> might want to consider reusing unionfs instead of rewriting it.

I *am* actually considering reusing unionfs, because this will result in
a far more reliable code in a shorter time.

>> Let me first expose my understanding of the term ``unionmount
>> functionality''. Usually (when doing settrans) the translator being set
>> on a node (directory) foo/ obscures the directory structure lying under
>> foo/. The essence of the unionmount idea here is to mount the translator
>> is such a way that the filesystem the translator makes public *merge*
>> with the underlying filesystem.
>> As far as the stand-alone implementation is concerned, I think we should
>> borrow as much ideas as possible from unionfs. Firstly, unionmount
>> should most probably be a libnetfs-based translator. Now let us go
>> further: 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''). When
>> unionmount is starting, it has (of course) a port to the underlying
>> node, which means that it has full access to its underlying
>> filesystem. Now, it can create a shadow node, mirroring the underlying
>> node and then set the Translator on this shadow node. The purpose of
>> this is to keep the Translator away from the real underlying node,
>> giving it at the same time all the information it should require.
> So the only difference between unionmount and unionfs is the setup and
> the shadow node, right?

Yep, that's it :-) (in my understanding)

> Then it might be possible to implement the shadow node in unionmount
> and pass it to unionfs.  Just wrap a file descriptor around the port
> and let unionfs inherit it, to make unionfs use it pass `/dev/fd/$FD'
> as an argument.
> 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.
> 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.  The only real question is wheather they
> are independant enough to be put in their own server.

Yep, I'm really uncomfortable about keeping around processes, but in
this case I'm inclined to think that spawning an extra process would be
an overkill. I'm more inclined to the simpler variant of borrowing the
code from unionfs, stripping off the unnecessary features and modifying
the startup sequence to get a new translator. This would yield faster
code (no extra context switch, the shadow node is within the main
translator) and more control over the merging functionality. You see, I
suppose that some time later we will be adding some specific merging
rules, which would be very difficult (if not impossible) with the
approach you are suggesting (about reusing unionfs as a whole).

I like the idea of a shadow-node server :-) However, I would rather keep
shadow-nodes inside processes, because they are cheap as compared to
RPCs and you have full control over them. Moreover, some translators
(like unionfs and hence unionmount) would like to keep a list of nodes
they own and drop nodes when they don't need them. This policy would
require more effort if a shadow-node server is involved.

> I have only followed discussions on nsmux lightly, so there might be
> some missunderstandings.  Please, have this in mind.

No problem; you look surprisingly good in nsmux matters :-)

>> [snip]
>> As I have already mentioned, I am personally more inclined to implement
>> the unionmount functionality as a stand-alone translator first, because
>> this approach preserves modularity. I am aware of the performance issue
>> about extra context switches, but if the unionmount translator will not
>> give off ports to its own nodes, but ports to *external* nodes
>> (underlying filesystem nodes or those published by the Translator), it
>> will not take part in the frequent (and most time-critical) I/O
>> operations and act as an initial source of ports only. I think it is
>> reasonable for unionmount not to create proxy nodes (in nsmux
>> terminology), because I cannot presently invent a use case where it will
>> need control over the ports it gave off to the client.
> Your resoning here seems solid to me, I say drop the library approach.
> :-)

Thanks for support :-) I'm waiting for antrik's opinion now :-)


reply via email to

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