<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 16, 2017 at 12:02 PM, Xavier Hernandez <span dir="ltr"><<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15/06/17 11:50, Pranith Kumar Karampuri wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Thu, Jun 15, 2017 at 11:51 AM, Ashish Pandey <<a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a>>> wrote:<br>
<br>
Hi All,<br>
<br>
We have been facing some issues in disperse (EC) volume.<br>
We know that currently EC is not good for random IO as it requires<br>
READ-MODIFY-WRITE fop<br>
cycle if an offset and offset+length falls in the middle of strip size.<br>
<br>
Unfortunately, it could also happen with sequential writes.<br>
Consider an EC volume with configuration 4+2. The stripe size for<br>
this would be 512 * 4 = 2048. That is, 2048 bytes of user data<br>
stored in one stripe.<br>
Let's say 2048 + 512 = 2560 bytes are already written on this<br>
volume. 512 Bytes would be in second stripe.<br>
Now, if there are sequential writes with offset 2560 and of size 1<br>
Byte, we have to read the whole stripe, encode it with 1 Byte and<br>
then again have to write it back.<br>
Next, write with offset 2561 and size of 1 Byte will again<br>
READ-MODIFY-WRITE the whole stripe. This is causing bad performance.<br>
<br>
There are some tools and scenario's where such kind of load is<br>
coming and users are not aware of that.<br>
Example: fio and zip<br>
<br>
Solution:<br>
One possible solution to deal with this issue is to keep last stripe<br>
in memory.<br>
This way, we need not to read it again and we can save READ fop<br>
going over the network.<br>
Considering the above example, we have to keep last 2048 bytes<br>
(maximum) in memory per file. This should not be a big<br>
deal as we already keep some data like xattr's and size info in<br>
memory and based on that we take decisions.<br>
<br>
Please provide your thoughts on this and also if you have any other<br>
solution.<br>
<br>
<br>
Just adding more details.<br>
The stripe will be in memory only when lock on the inode is active.<br>
</div></div></blockquote>
<br>
I think that's ok.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One<br>
thing we are yet to decide on is: do we want to read the stripe<br>
everytime we get the lock or just after an extending write is performed.<br>
I am thinking keeping the stripe in memory just after an extending write<br>
is better as it doesn't involve extra network operation.<br>
</blockquote>
<br></span>
I wouldn't read the last stripe unconditionally every time we lock the inode. There's no benefit at all on random writes (in fact it's worse) and a sequential write will issue the read anyway when needed. The only difference is a small delay for the first operation after a lock.<br></blockquote><div><br></div><div>Yes, perfect.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What I would do is to keep the last stripe of every write (we can consider to do it per fd), even if it's not the last stripe of the file (to also optimize sequential rewrites).<br></blockquote><div><br></div><div>Ah! good point. But if we remember it per fd, one fd's cached data can be over-written by another fd on the disk so we need to also do cache invalidation. May be implementation should consider this possibility. Yet to think about how to do this. But it is a good point. We should consider this.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
One thing I've observed is that a 'dd' with block size of 1MB gets split into multiple 128KB blocks that are sent in parallel and not necessarily processed in the sequential order. This means that big block sizes won't benefit much from this optimization since they will be seen as partially non-sequential writes. Anyway the change won't hurt.<br></blockquote><div><br></div><div>In this case as per the solution we won't cache anything right? Because we didn't request anything from the disk. We will only keep the data in cache if it is not aligned write which is at the current EOF. At least that is what I had in mind.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Xavi<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
<br>
<br>
---<br>
Ashish<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Gluster-devel mailing list<br></span>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a> <mailto:<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.<wbr>org</a>><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br>
<<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mail<wbr>man/listinfo/gluster-devel</a>><br>
<br>
<br>
<br><span class="HOEnZb"><font color="#888888">
<br>
--<br>
Pranith<br>
</font></span></blockquote>
<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>