hi,
the problem with using a stripeset on the physical block device level is that any kind of parity information only protects you from failures within the node, not from a failure of the entire node itself. and with striping, it should behave like a block-ish device. anyway, in our situation now, it's ok not to have it (we just need more bricks, but then replication also has other benefits). the plans for 3.4 you mentioned - where can i read about it? unfortunately, my expertise is not in c … i'm a java guy (although i would LOVE to contribute, i just feel a bit unable to) .rm > The short answer is that GlusterFS is not a block device. > > Sure, striping exists and could possibly support a parity translator in RAID > fashion, but the stripe translator isn't, imho, anywhere close to as > functional as raid ( > http://joejulian.name/blog/should-i-use-stripe-on-glusterfs/ ). Fault > tolerance, self-healing, split-brain, etc. are all much more difficult to > manage when you're not connecting your block storage to the raid controller > and are, instead, storing stripes and parities of files in a filesystem > instead of on blocks. > > It's not a definite no, though. 3.4 includes a block-device translator for > exposing raw block devices. Perhaps that could be utilized in a way that > parity striping might eventually happen. I'm sure that if someone were to > write a translator that worked, it would be happily accepted into the project. > _______________________________________________ > Gluster-users mailing list > [email protected] > http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________ Gluster-users mailing list [email protected] http://supercolony.gluster.org/mailman/listinfo/gluster-users
