Hi Keisuke-san, On Tue, Jun 17, 2008 at 05:33:52PM +0900, Keisuke MORI wrote: > Dejan, > > Thank you for taking care of it. > > Yes, NTT is very glad and agrees to include sfex into the > heartbeat repository! > > Dejan Muhamedagic <[EMAIL PROTECTED]> writes: > > > Hello, > > > > Since last year NTT designed and implemented sfex, a suite of > > programs to improve shared disk usage (see linux-ha.org/sfex) > > which unfortunately didn't attract attention it deserves. I > > reviewed the code and attached you'll find some comments and some > > simple changes. One general remark: all programs (sfex_*) are > > monolithic and, though they are not that big, it would be > > beneficial to code readers if they were split into more > > units/functions. > > That sounds reasonable. > Where can I find your comments and modifications?
A reasonable question :) Forgot to attach the file with comments. Sorry about that. It is in the form of a patch against version 1.3. > > A couple of suggestions on making sfex useful in other contexts > > were making a quorum plugin and a HBcomm plugin. Did you > > investigate further these options? > > > Yes we did but we think that > those would be totally different approach from sfex. > > > - a quorum plugin > > A quorum plugin is executed only on 'the cluster leader node' in CCM, I don't think so. CCM delivers connectivity and quorum information on each node. However, that's probably not relevant. > and it does not care where the resource is running on, > whereas sfex should run on the same node which the resource > in question is running on because it's for the protection of > the data which resides in the resource. > > In other words, sfex is to control with resource granularity, > whereas a quorum plugin is to control 'the partition' granularity. Right. The point was however to use parts of sfex for the quorum functionality. I'll see if I can get back to you with a more detailed and specific proposal. > - HBcomm plugin > > I remember that somebody posted this before, called 'dskcm'. Somehow missed that one. > This is also interesting idea but the approach is very different. > > This approach is: > - having yet another redundant communication path through > the shared medium. > whereas sfex's approach is: > - provide a protection method when ALL of the communication > paths are failed. > > Even though they have the similar goal the functionality is > very different. Yes. Though again sfex would need to be twisted a bit to provide heartbeats over shared storage. I'll take a look at dskcm. Cheers, Dejan
sfex-comments.gz
Description: GNU Zip compressed data
_______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
