Re: Feature requests of glusterfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux