<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/18/2013 01:51 PM, ruben malchow
wrote:<br>
</div>
<blockquote
cite="mid:7DB4261D-6F9C-4DB0-B330-AC5C0BCEF90C@gmail.com"
type="cite">
<pre wrap="">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?
</pre>
</blockquote>
The short answer is that GlusterFS is not a block device. <br>
<br>
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 (
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="http://joejulian.name/blog/should-i-use-stripe-on-glusterfs/">http://joejulian.name/blog/should-i-use-stripe-on-glusterfs/</a>
). 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.<br>
<br>
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.<br>
</body>
</html>