Re: Unionmount. Basic details

[olafBuddenhagen]

Hi,

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.

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

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.

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

-antrik-