Re: [Gluster-devel] Feature requests of glusterfs

[Kevan Benson]

LI Daobing wrote:
> On Jan 3, 2008 3:09 AM, Kevan Benson <address@hidden> 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.

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

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

--

-Kevan Benson
-A-1 Networks