hi, 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? .rm
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>
Hi Ruben, we are working on something like that, but it is not ready for production environments yet. Some stability and performance improvements must be done. We have recently published an initial alpha version on GitHub (https://github.com/datalab-bcn). However it is basically intended for developer testing until it matures. If you want/can test it we will be very happy to have some feedback and improve it. Xavi Al 18/02/13 22:51, En/na ruben malchow ha escrit:> > hi, > > 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? > > .rm > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users