The reason why I am not worried about data integrity is because the nodes accessing the data are not accessing the same spots on the filesystem. ie.. storage server has the data. node 1 accesses gfs mount/some_dir node 2 accesses gfs mount/some_other_dir node 3 accesses gfs mount/yet_some_other_dir Now of course if the storage server goes down the cluster should break and all nodes should stop, but if a node or multiple nodes go down, who cares, the cluster continues to work. That is what we are aiming for. gwood@xxxxxxxxxxxxxx wrote: >>Ok, so let me reiterate: >> >> If I don't even care about quorum and the cluster. I just want a >>filesystem that will server out a block device, which is what gfs does. >> >> >Not really. The whole point of GFS is that it shares a filesystem, not a >block device, and in a controlled manner. If you want a cluster aware >block device, that's a different issue - a lot of overlap, and it could be >implemented by using a loopback mount on top of gfs, but could be done >quite a bit simpler too I would have thought. > > > >>I'm not worried about "split brain" issues. >> >> >The GFS may not be the thing for you - especially if you're after a block >device. GFS, like almost all clustering products, treats data integrity >as the most important thing. The system is designed to die rather than >risk corrupting your data. > >Your database being unavailable for 15 minutes while you sort out a quorum >issue is much better for 99.9999% of people than allowing it to run and >totally corrupting the data - that's one of the reasons behind the way it >works. > >I'm not saying that GFS cannot do what you are after - hell, if necessary, >a patch to allow you to force the number of quorum votes shouldn't be that >difficult - but you do seem to be trying to force a square peg into a >round hole. > >-- > >Linux-cluster@xxxxxxxxxx >http://www.redhat.com/mailman/listinfo/linux-cluster > > > -- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
