[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: Fri, 10 Apr 2009 20:51:03 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

<olafBuddenhagen@gmx.net> writes:
> On Wed, Apr 08, 2009 at 08:17:30PM +0300, Sergiu Ivanov wrote:
>> 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).
> On the contrary -- having the merging functionality in a separate
> component, would make it easier to replace it...

Completely agreed, but if this separate component is unionfs, we will
anyway have to fork off its code base.

> As I already pointed out in different contexts (IIRC both in network
> virtualization and nsmux discussions), modularity always increases
> flexibility, at the cost of lower efficiency and higher overall
> complexity. (OTOH the complexity is partially isolated, which can reduce
> *local* complexity -- also one of the major advantages of microkernels
> and modular designs in general...)

Yes, I agree, and that is why I'm working on a project within a
microkernel OS :-)

> Still I agree with you that for the first implementation, it's probably
> better to fork the code and create a monolithic implementation, to keep
> things simple...

This is good :-) I also stand for simplicity in this problem, although I
like modularity, too (as I've pointed out above).

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

I am mainly concerned with the fact that dropping the node will require
accessing the shadow-node server (if I understand things correctly), and
invoking an RPC is always more effort than just cleaning up a local
piece of memory.


reply via email to

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