On Tue, 2006-02-14 at 08:02 -0500, Greg Forte wrote: > I have this exact same setup, and concluded that GFS would be less > trouble overall (though that conclusion is still open to re-evaluation > ;-) The problem, as I see it, is that if have your "shared" data on an > ext3 filesystem, then you want to make damn sure that the "failed" node > has unmounted (or simply ceased accessing) that filesystem before the > "backup" node mounts it and takes over the services. Fencing takes care of this... > If you have > hardware fencing then this is theoretically not a big problem, because > the failed node should get power cycled - but that's a BIG "should", and > there could be instances in which you want to switch the services over > without power cycling the "failed" node. ... and is plainly stated as a requirement on all Red Hat Cluster Suite 4 and Red Hat GFS 6.1 installations: http://www.redhat.com/docs/manuals/csgfs/browse/rh-cs-en/ch-hardware.html#S1-HARDWARE-CHOOSING http://www.redhat.com/docs/manuals/csgfs/browse/rh-gfs-en/s1-sysreq-iofence.html > Forcing an unmount of an ext3 > filesystem is dicey at best, and I just envisioned too many scenarios in > which both nodes ended up having the filesystem mounted simultaneously > and stomped all over the data. GFS lets you mount the file system on multiple nodes, but in the case of a network partition or live-hang where both nodes have the file system mounted, the GFS volume can easily become corrupt if fencing is not employed. That said, GFS makes it "nicer" and "quicker" to fail over: by the time rgmanager gets the "node-transition" event, fencing has already completed and GFS has already replayed the journal. With ext3, the journal is replayed during the mount on the new node. -- Lon -- Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
