[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: Mon, 6 Apr 2009 18:58:23 +0200
User-agent: Mutt/1.5.18 (2008-05-17)


On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:
> Hello,
> 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. These two approaches have there advantages and
> disadvantages. Implementing unionmount functionality in a stand-alone
> translator will involve an extra layer of translation (which would often
> mean an extra context switch in each operation), but will be more
> flexible in the meaning that to modify parts of functionality will
> require rebuilding a single translator. OTOH, implementing unionmount as
> extensions to translator libraries would mean faster operation and
> automatic inclusion of the functionality in *every* existing
> translators, but modifying something would require more effort. I am
> generally inclined to implement the functionality as a stand-alone
> translator first (though things might well show that this variant of
> implementation would be best (my personal opinion)), and moving things
> to lib{net,disk}fs later on.

I think the first approach is the better of the two.  However, you
might want to consider reusing unionfs instead of rewriting it.

> 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?

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.

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

> [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.


reply via email to

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