[Gluster-users] parity translator?

[Joe Julian]

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>