On 02/18/2013 01:51 PM, ruben malchow wrote: > another question that keeps popping up here is this: why isnt there anything like a parity translator that - in combination with striping - takes n+x subvolumes and writes n blocks plus x copies of parity information? wouldn't this make sense for making striping more robust against failures? am i misunderstanding basic concepts again or would a somewhat RAID-like behaviour make it easier to balance robustness against failures against space used? > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130218/e3d3332a/attachment.html>
