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-
