Hello, On Jan 4, 2008 2:11 AM, Kevan Benson <kbenson@xxxxxxxxxxxxxxx> wrote: > 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. 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
