<html><body><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><br></div><div>---<br></div><div>Ashish<br></div><div><br></div><div><br></div></div></body></html>