Re: Unionmount. Basic details

[Sergiu Ivanov]

Hello,

<olafBuddenhagen@gmx.net> writes:
> On Fri, Apr 10, 2009 at 08:51:03PM +0300, Sergiu Ivanov wrote:
>> <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.
>
> Not at all -- the idea is to use something completely different instead
> of unionfs, if we require different functionality...
>
> Having the merging code in a separate component (be it unionfs or
> something more specialized), would indeed make it easier to use
> different policies. However, the complexity involved makes me object to
> such an approach, at least in the initial implementation.

This was the thing that made me a better adept of the forking idea.

> Note that at the beginning of the namespace based translator selection
> project, I suggested handling various special syntax in external
> components (like the filter), instead of hard-coding it in nsmux, to
> gain more flexibility. I believed it would simplify the design, because
> this way we wouldn't have to think about the various policies when
> working on nsmux itself. I wasn't aware how much the added complexity of
> the modular approach will make it harder to figure out the basics; how
> much it will frustrate progress...

Yes, I remember our discussion on that matter...

> We are in a very similar situation here -- but I have learned from last
> time. Go for the simple approach first, and only later think about a
> more flexible solution. We have a deadline to meet.

OK. I think I've got the idea :-)

>> >> 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.
>
> Ah, I wasn't aware that you were talking about monolitic implementation
> vs. external implementation of internal nodes here... In that case, I
> totally agree.
>
> I thought you referred to individual processes for each internal node
> vs. a central server for them -- which, as I said elsewhere, doesn't
> make much of a difference I believe.

I see... I cannot see why it should make difference, either.

Regards,
scolobb