Re: Unionmount. Basic details

[Sergiu Ivanov]

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

Regards,
scolobb