<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 15, 2017 at 11:51 AM, Ashish Pandey <span dir="ltr"><<a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a>></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-family:times new roman,new york,times,serif;font-size:12pt;color:#000000"><div>Hi All,<br></div><div><br></div><div>We have been facing some issues in disperse (EC) volume.<br></div><div>We know that currently EC is not good for random IO as it requires READ-MODIFY-WRITE fop</div><div>cycle if an offset and offset+length falls in the middle of strip size.<br></div><div><br></div><div>Unfortunately, it could also happen with sequential writes.</div><div> Consider an EC volume with configuration 4+2. The stripe size for this would be 512 * 4 = 2048. That is, 2048 bytes of user data stored in one stripe.<br></div><div>Let's say 2048 + 512 = 2560 bytes are already written on this volume. 512 Bytes would be in second stripe.<br></div><div>Now, if there are sequential writes with offset 2560 and of size 1 Byte, we have to read the whole stripe, encode it with 1 Byte and then again have to write it back.<br></div><div>Next, write with offset 2561 and size of 1 Byte will again READ-MODIFY-WRITE the whole stripe. This is causing bad performance.<br></div><div><br></div><div>There are some tools and scenario's where such kind of load is coming and users are not aware of that.<br></div><div>Example: fio and zip<br></div><div><br></div><div>Solution: <br></div><div>One possible solution to deal with this issue is to keep last stripe in memory. </div><div>This way, we need not to read it again and we can save READ fop going over the network.</div><div> Considering the above example, we have to keep last 2048 bytes (maximum) in memory per file. This should not be a big </div><div>deal as we already keep some data like xattr's and size info in memory and based on that we take decisions.<br></div><div><br></div><div>Please provide your thoughts on this and also if you have any other solution.<br></div></div></div></blockquote><div><br></div><div>Just adding more details.<br></div><div>The stripe will be in memory only when lock on the inode is active. One thing we are yet to decide on is: do we want to read the stripe everytime we get the lock or just after an extending write is performed. I am thinking keeping the stripe in memory just after an extending write is better as it doesn't involve extra network operation.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:times new roman,new york,times,serif;font-size:12pt;color:#000000"><div></div><div><br></div><div>---<br></div><div>Ashish<br></div><div><br></div><div><br></div></div></div><br>______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div></div>