Re: [Linux-cluster] A few GFS newbie questions: journals, etc

[Jon Scottorn <jscottorn possibilityforge com>]

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 dragonhold org 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 mailing list
>Linux-cluster redhat com
>http://www.redhat.com/mailman/listinfo/linux-cluster
>
>  
>