<p>Jeff that came from one of you core glusterfs engineers (sid?). According to him the term stripe isn't used correctly and does not imply parallel operations. Writes are handled one brick at a time. If a stripe were parallel tje my 800 Mbs should have been closer to 2GB across three servers each capable of 900 MB/s all day long. If you have docs that say otherwise I'd love to see them.</p>
<p>Corey</p>
<div class="gmail_quote">On Oct 18, 2012 8:19 AM, "Jeff Darcy" <<a href="mailto:jdarcy@redhat.com">jdarcy@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/18/2012 09:39 AM, Corey Kovacs wrote:<br>
> My experiences so far were sort of disappointing until I found out a few key<br>
> items about GlusterFS which I'd taken for granted.<br>
><br>
> 1. Stripes are not what you might think. The I/O for a stripe does _not_ fan<br>
> out as in a raid card. It's an unfortunate use of the term only describing and<br>
> allowing you to store files larger than the max size of a single brick.<br>
<br>
I'm not sure what you mean by "don't fan out" because stripe *will* issue<br>
multiple requests in parallel. It's just not that beneficial most of the time,<br>
because the overhead of splitting and recombining writes tends to overwhelm the<br>
advantage of parallelism. Some people might have different results, especially<br>
on faster networks, but we don't push it as a general-purpose performance<br>
enhancer because it doesn't work that way for most people.<br>
<br>
> 2. I/O is done in sync mode so cache coherency isn't an issue and to ensure the<br>
> integrity of the data written.<br>
<br>
Generally true only for metadata - not for data. We do honor O_SYNC and such<br>
when we see them, of course, but otherwise we're quite happy to buffer writes<br>
in write-behind, cache reads in io-cache, etc.<br>
<br>
> 3. The performance of a distributed volume far exceeds that of a stripe for my<br>
> use. Again, depends on the size of the bricks.<br>
<br>
...and the size of the I/O requests, and a bunch of other things.<br>
<br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br>
</blockquote></div>