[Gluster-devel] Feature requests of glusterfs

[LI Daobing]

Hello,
On Jan 4, 2008 2:11 AM, Kevan Benson <kbenson at a-1networks.com> wrote:
> LI Daobing wrote:
> > On Jan 3, 2008 3:09 AM, Kevan Benson <kbenson at a-1networks.com> wrote:
> >> LI Daobing wrote:
> > In your model, if a middle node out of work, then all the following
> > nodes out of work. (isn't it?) I think this is very dangerous for afr.
>
> Yes, I admitted that was a good key feature of your proposal.
>
> > And more, there is a comment near the end of definition of
> > afr_sync_ownership_permission. This comment said that afr on afr wont
> > work. This function is triggered by afr_lookup_cbk when self_heal is
> > needed. And self_heal is very important for afr.
> >
> > Any one can help clear whether afr on afr has problem?
>
> Yes, thinking about it now, I an see at least one reason why it probably
> wouldn't work (afr extended attributes clash).  The devs expressed
> interest in chaining AFR before, so maybe it will become a reality in
> the future.

This point sounds a small bug. Hope it can be fixed soon.

>
> >> The only thing your translators provide that isn't already available
> >> through chained translators is automatic reconfiguration of the chain
> >> members when a server drops out, which is a good feature, but I would
> >> rather just add cheap redundant hardware to boost speed, such as extra
> >> gigabit NICs and switches to allow dedicated paths between select
> >> systems.  Also, maybe the new switch translator can be added to what's
> >> already available to achieve what you want, I'm still fuzzy on exactly
> >> what it can be used for.
> >
> > It's a good idea to buy more and better hardware. But it's better if
> > we can achive this by software. :)
>
> My argument wasn't so much hardware vs. software, but cheap effective
> hardware vs. complex software.  Fail-over can get tricky, especially
> when done because a node one or two steps removed from the originating
> request fails.  The more complex a fail-ever system is, the more I tend
> to distrust it.

Hmm, I agree with you on this point.

>
> >>> PS, should I copy this feature request to wiki? Or it's ok to only put
> >>> it here?
> >> OK, now that I've done my best to tear down your proposal and say why
> >> it's not needed, here's where I put my disclaimer:
> >>
> >> 1) I'm not a dev, and I haven't really looked into the code, so I don't
> >> know how easy or hard your proposal is to actually implement.
> >> 2) I'm just one person, and even though *I* may think it's not needed,
> >> others may differ on this point.
> >>
> >
> > Thanks for your comment.
>
> Thanks for being good natured about the response.
>
>
:)


-- 
Best Regards,
 LI Daobing