Re: Unionmount. Basic details

[olafBuddenhagen]

Hi,

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

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

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

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

-antrik-