Bug 1512447 - [disperse] Keep stripe in in-memory cache for the non aligned write
Summary: [disperse] Keep stripe in in-memory cache for the non aligned write
Keywords:
Status: CLOSED EOL
Alias: None
Product: GlusterFS
Classification: Community
Component: disperse
Version: 3.13
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
Assignee: Ashish Pandey
QA Contact:
URL:
Whiteboard:
Depends On: 1471753
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-13 09:24 UTC by Ashish Pandey
Modified: 2018-06-20 18:27 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1471753
Environment:
Last Closed: 2018-06-20 18:27:18 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Ashish Pandey 2017-11-13 09:24:44 UTC
+++ This bug was initially created as a clone of Bug #1471753 +++

Description of problem:

   
    Problem:
    Consider an EC volume with configuration  4 + 2.
    The stripe size for this would be 512 * 4 = 2048.
    That means, 2048 bytes of user data stored in one
    stripe. Let's say 2048 + 512 = 2560 bytes are
    already written on this volume. 512 Bytes would
    be in second stripe. 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. Next, write with
    offset 2561 and size of 1 Byte will again
    READ-MODIFY-WRITE the whole stripe. This is causing
    bad performance because of lots of READ request
    travelling over the network.
    
    There are some tools and scenario's where such kind
    of load is coming and users are not aware of that.
    Example: fio and zip
    
    Solution:
    One possible solution to deal with this issue is to
    keep last stripe in memory. This way, we need not to
    read it again and we can save READ fop going over the
    network. Considering the above example, we have to
    keep last 2048 bytes (maximum) in memory per file.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

--- Additional comment from Worker Ant on 2017-07-17 08:24:29 EDT ---

REVIEW: https://review.gluster.org/17789 (cluster/ec: Keep last written strip in in-memory cache) posted (#1) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Worker Ant on 2017-07-19 01:39:03 EDT ---

REVIEW: https://review.gluster.org/17789 (cluster/ec: Keep last written strip in in-memory cache) posted (#2) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Worker Ant on 2017-07-23 04:47:53 EDT ---

REVIEW: https://review.gluster.org/17789 (cluster/ec: Keep last written strip in in-memory cache) posted (#3) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Worker Ant on 2017-08-21 01:31:04 EDT ---

REVIEW: https://review.gluster.org/17789 (cluster/ec: Keep last written strip in in-memory cache) posted (#4) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Worker Ant on 2017-09-18 06:45:22 EDT ---

REVIEW: https://review.gluster.org/17789 (Problem: Consider an EC volume with configuration  4 + 2. The stripe size for this would be 512 * 4 = 2048. That means, 2048 bytes of user data stored in one stripe. Let's say 2048 + 512 = 2560 bytes are already written on this volume. 512 Bytes would be in second stripe. 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. Next, write with offset 2561 and size of 1 Byte will again READ-MODIFY-WRITE the whole stripe. This is causing bad performance because of lots of READ request travelling over the network.) posted (#5) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Worker Ant on 2017-09-18 06:55:48 EDT ---

REVIEW: https://review.gluster.org/17789 (cluster/ec: Keep last written strip in in-memory cache) posted (#6) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Worker Ant on 2017-09-22 04:26:54 EDT ---

REVIEW: https://review.gluster.org/17789 (cluster/ec: Keep last written strip in in-memory cache) posted (#7) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Worker Ant on 2017-10-03 08:35:56 EDT ---

REVIEW: https://review.gluster.org/17789 (cluster/ec: Keep last written strip in in-memory cache) posted (#8) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Worker Ant on 2017-10-03 13:51:33 EDT ---

REVIEW: https://review.gluster.org/17789 (cluster/ec: Keep last written strip in in-memory cache) posted (#9) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Worker Ant on 2017-10-04 03:51:44 EDT ---

REVIEW: https://review.gluster.org/17789 (cluster/ec: Keep last written strip in in-memory cache) posted (#10) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Worker Ant on 2017-10-05 06:30:10 EDT ---

REVIEW: https://review.gluster.org/17789 (cluster/ec: Keep last written strip in in-memory cache) posted (#11) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Worker Ant on 2017-10-09 13:20:46 EDT ---

REVIEW: https://review.gluster.org/17789 (cluster/ec: Keep last written strip in in-memory cache) posted (#12) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Worker Ant on 2017-11-10 17:16:13 EST ---

COMMIT: https://review.gluster.org/17789 committed in master by  

------------- cluster/ec: Keep last written strip in in-memory cache

Problem:
Consider an EC volume with configuration  4 + 2.
The stripe size for this would be 512 * 4 = 2048.
That means, 2048 bytes of user data stored in one
stripe. Let's say 2048 + 512 = 2560 bytes are
already written on this volume. 512 Bytes would
be in second stripe. 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. Next, write with
offset 2561 and size of 1 Byte will again
READ-MODIFY-WRITE the whole stripe. This is causing
bad performance because of lots of READ request
travelling over the network.

There are some tools and scenario's where such kind
of load is coming and users are not aware of that.
Example: fio and zip

Solution:
One possible solution to deal with this issue is to
keep last stripe in memory. This way, we need not to
read it again and we can save READ fop going over the
network. Considering the above example, we have to
keep last 2048 bytes (maximum) in memory per file.

Change-Id: I3f95e6fc3ff81953646d374c445a40c6886b0b85
BUG: 1471753
Signed-off-by: Ashish Pandey <aspandey>

Comment 1 Worker Ant 2017-11-22 17:20:33 UTC
REVIEW: https://review.gluster.org/18844 (cluster/ec: Keep last written strip in in-memory cache) posted (#1) for review on release-3.13 by Ashish Pandey

Comment 2 Shyamsundar 2018-06-20 18:27:18 UTC
This bug reported is against a version of Gluster that is no longer maintained (or has been EOL'd). See https://www.gluster.org/release-schedule/ for the versions currently maintained.

As a result this bug is being closed.

If the bug persists on a maintained version of gluster or against the mainline gluster repository, request that it be reopened and the Version field be marked appropriately.

Comment 3 Shyamsundar 2018-06-20 18:27:49 UTC
This bug reported is against a version of Gluster that is no longer maintained
(or has been EOL'd). See https://www.gluster.org/release-schedule/ for the
versions currently maintained.

As a result this bug is being closed.

If the bug persists on a maintained version of gluster or against the mainline
gluster repository, request that it be reopened and the Version field be marked
appropriately.


Note You need to log in before you can comment on or make changes to this bug.