Wow, the response is overwhelming! I've also got request for a summary. Thanks to: Thomas M. Payerle Scott Howard Kevin Buterbaugh Dan Astoorian David Newton ddunham@tsg.taos.com Matt Harris Paul Robertson Chris Barnard Richard Mackerras Julie Peers Manish Oberai M.Lambrechts@pcmuitgevers.nl The majority response confirmed that there is a way of disabling/loosening the >50% quorum requirement, which is put this line in the /etc/system and reboot (for DiskSuite 4.2.1 and newer): set md:mirrored_root_flag=1 However, there is a reason why the quorum needs to be greater than 50%. SDS works using MCA - Majority Concensus Algorithm. When metadb disagrees on who is updated and who should be sync'ed up, it looks at what the majority of the db replicas say and decide for the majority. If only half of the db replicas remain, there is no majority and as a result, disksuite won't be able to make a decision as to what is in sync and what is out. Scott mentioned that "I've just checked the source code, and it looks like it's pretty much a first-in-best-dressed case if the metadb's are out of sync." IN a root-mirroring scenario, it won't be much of an issue provided that one disk failed and not going to be re-used with the metadb intact. But if you are going to plug that disk back in and reboot the machine with disabled quorum, you may be in for some unpleasant surprises. One concensus is that since the machine shouldn't crash due to a disk failure, after the failure is detected, one can easily remove the the metadevice replicas from the bad disk. Then a reboot doesn't have any issues. Dan graciously provided this link for reference: http://www.sunmanagers.org/pipermail/sunmanagers/2002-June/013859.html Paul provided the following: http://unixway.com/vm/disksuite/mirroros.html Zaigui HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Wed Oct 30 02:34:03 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:56 EST