Done.<br><br><a href="https://bugzilla.redhat.com/show_bug.cgi?id=888174">https://bugzilla.redhat.com/show_bug.cgi?id=888174</a><br><br>While testing the system, we found 3.3.0 enables stripped-replicated volumes and seems to offer a &quot;right&quot; read behaviour in some tests.<br>
<br>Thanks in advance and, please, contact me in case I can offer further help.<br><br>Best regards,<br>Samuel.<br><br><div class="gmail_quote">On 17 December 2012 16:20, John Mark Walker <span dir="ltr">&lt;<a href="mailto:johnmark@redhat.com" target="_blank">johnmark@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif">Please file a bug. There might be time to fix read performance before the 1st beta release.<br>
<br>-JM<br><br><br><hr><blockquote style="padding-left:5px;font-size:12pt;font-style:normal;margin-left:5px;font-family:Helvetica,Arial,sans-serif;text-decoration:none;font-weight:normal;border-left:2px solid rgb(16,16,255)">
<div><div class="h5">Dear folks,<br><br>I&#39;ve been tried to use replicated stripped volumes with 3.3. unsuccessfully due to <a href="https://bugzilla.redhat.com/show_bug.cgi?id=861423" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=861423</a> and I then proceed to try 3.4.0qa5. I then find out that the bug was solved and I could use replicated stripped volume with the new version. Amazingly, write performance was quite astonishing.<br>

<br>The problem I&#39;m facing now is in the read process: It&#39;s horribly slow. When I open a file to edit using the gluster native client, it takes a few seconds and sometimes I got an error refering to file has been modified while I was editing it. There&#39;s a ruby application reading the files and I got continuously timeout errors.<br>

<br>I&#39;m using 4 bricks with Centos 6.3 with the following structure:<br>Type: Striped-Replicate<br>Volume ID: 23dbb8dd-5cb3-4c71-9702-7c16ee9a3b3b<br>Status: Started<br>Number of Bricks: 1 x 2 x 2 = 4<br>Transport-type: tcp<br>

Bricks:<br>Brick1: 10.0.51.31:/gfs<br>Brick2: 10.0.51.32:/gfs<br>Brick3: 10.0.51.33:/gfs<br>Brick4: 10.0.51.34:/gfs<br>Options Reconfigured:<br>performance.quick-read: on<br>performance.io-thread-count: 32<br>performance.cache-max-file-size: 128MB<br>

performance.cache-size: 256MB<br>performance.io-cache: on<br>cluster.stripe-block-size: 2MB<br>nfs.disable: on<br><br>I started profiling and found out one node with absurd latency figures. I stopped the node and the problem moved to another brick:<br>

 %-latency   Avg-latency   Min-Latency   Max-Latency   No. of calls         Fop<br> ---------   -----------   -----------   -----------   ------------        ----<br> 99.94  551292.41 us      10.00 us 1996709.00 us            361    FINODELK<br>

<br>Could anyone provide some information how to debug this problem? Currently the volume is not usable due to the horrible delay.<br><br>Thank you very much in advance,<br>Samuel.<br>
<br></div></div>_______________________________________________<br>Gluster-users mailing list<br><a href="mailto:Gluster-users@gluster.org" target="_blank">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></blockquote>
<br></div></div></blockquote></div><br>