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. 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. 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. So, the short version is: GFS is designed for this sort of thing, ext3 isn't. BTW, LVM and GFS certainly aren't mutually exclusive. I'm using GFS/LVM with my SAN because the 'optimal' setup with the unit is to have two separate raid5 stripes (because of the reserved area for the SAN OS on some, but not all, of the disks), but I still wanted all of the available space in one big chunk. As to resizing a GFS filesystem: http://www.redhat.com/docs/manuals/csgfs/browse/rh-gfs-en/s1-manage-growfs.html -g Weyns, Frank wrote: > Hi, > > I'm building a two node HA oracle cluster on Redhat. (One active > production node and a stand-by node with a test application, which can > be shutdown if needed. local system disks, stroage on SAN) > > The question is: > Which underlying Filesytem to use ? > We would prefer to use LVM with ext3 (stable , resize if needed, > experience and knowledge in house) > > But everybody seems to use GFS: > Why ? > What are the advantages to LVM-ext3 ? > and > If we use GFS, what are the things to keep in mind ? > > /Frank Weyns > -- > > Disclaimer > > Dit bericht met eventuele bijlagen is vertrouwelijk en uitsluitend > bestemd voor de geadresseerde. Indien u niet de bedoelde ontvanger bent, > wordt u verzocht de afzender te waarschuwen en dit bericht met eventuele > bijlagen direct te verwijderen en/of te vernietigen. Het is niet > toegestaan dit bericht en eventuele bijlagen te vermenigvuldigen, door > te sturen, openbaar te maken, op te slaan of op andere wijze te > gebruiken. Ordina N.V. en/of haar groepsmaatschappijen accepteren geen > verantwoordelijkheid of aansprakelijkheid voor schade die voortvloeit > uit de inhoud en/of de verzending van dit bericht. > > This e-mail and any attachments are confidential and is solely intended > for the addressee only. If you are not the intended recipient, please > notify the sender and delete and/or destroy this message and any > attachments immediately. It is prohibited to copy, to distribute, to > disclose or to use this e-mail and any attachments in any other way. > Ordina N.V. and/or its group companies do not accept any responsibility > nor liability for any damage resulting from the content of and/or the > transmission of this message. > > > ------------------------------------------------------------------------ > > -- > > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
