[Gluster-devel] Feature requests of glusterfs

[Kevan Benson]

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.

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