17b94a
From 52d71ad0e5c27808e7d8eea8a0920298837e408c Mon Sep 17 00:00:00 2001
17b94a
From: Xavi Hernandez <xhernandez@redhat.com>
17b94a
Date: Wed, 17 Jul 2019 14:50:22 +0200
17b94a
Subject: [PATCH 271/276] cluster/ec: fix EIO error for concurrent writes on
17b94a
 sparse files
17b94a
17b94a
EC doesn't allow concurrent writes on overlapping areas, they are
17b94a
serialized. However non-overlapping writes are serviced in parallel.
17b94a
When a write is not aligned, EC first needs to read the entire chunk
17b94a
from disk, apply the modified fragment and write it again.
17b94a
17b94a
The problem appears on sparse files because a write to an offset
17b94a
implicitly creates data on offsets below it (so, in some way, they
17b94a
are overlapping). For example, if a file is empty and we read 10 bytes
17b94a
from offset 10, read() will return 0 bytes. Now, if we write one byte
17b94a
at offset 1M and retry the same read, the system call will return 10
17b94a
bytes (all containing 0's).
17b94a
17b94a
So if we have two writes, the first one at offset 10 and the second one
17b94a
at offset 1M, EC will send both in parallel because they do not overlap.
17b94a
However, the first one will try to read missing data from the first chunk
17b94a
(i.e. offsets 0 to 9) to recombine the entire chunk and do the final write.
17b94a
This read will happen in parallel with the write to 1M. What could happen
17b94a
is that half of the bricks process the write before the read, and the
17b94a
half do the read before the write. Some bricks will return 10 bytes of
17b94a
data while the otherw will return 0 bytes (because the file on the brick
17b94a
has not been expanded yet).
17b94a
17b94a
When EC tries to recombine the answers from the bricks, it can't, because
17b94a
it needs more than half consistent answers to recover the data. So this
17b94a
read fails with EIO error. This error is propagated to the parent write,
17b94a
which is aborted and EIO is returned to the application.
17b94a
17b94a
The issue happened because EC assumed that a write to a given offset
17b94a
implies that offsets below it exist.
17b94a
17b94a
This fix prevents the read of the chunk from bricks if the current size
17b94a
of the file is smaller than the read chunk offset. This size is
17b94a
correctly tracked, so this fixes the issue.
17b94a
17b94a
Also modifying ec-stripe.t file for Test #13 within it.
17b94a
In this patch, if a file size is less than the offset we are writing, we
17b94a
fill zeros in head and tail and do not consider it strip cache miss.
17b94a
That actually make sense as we know what data that part holds and there is
17b94a
no need of reading it from bricks.
17b94a
17b94a
Upstream-patch: https://review.gluster.org/c/glusterfs/+/23066
17b94a
Change-Id: Ic342e8c35c555b8534109e9314c9a0710b6225d6
17b94a
fixes: bz#1731448
17b94a
Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
17b94a
Reviewed-on: https://code.engineering.redhat.com/gerrit/177975
17b94a
Tested-by: RHGS Build Bot <nigelb@redhat.com>
17b94a
Reviewed-by: Sunil Kumar Heggodu Gopala Acharya <sheggodu@redhat.com>
17b94a
---
17b94a
 tests/basic/ec/ec-stripe.t              |  2 +-
17b94a
 xlators/cluster/ec/src/ec-inode-write.c | 26 +++++++++++++++++---------
17b94a
 2 files changed, 18 insertions(+), 10 deletions(-)
17b94a
17b94a
diff --git a/tests/basic/ec/ec-stripe.t b/tests/basic/ec/ec-stripe.t
17b94a
index 1e940eb..98b9229 100644
17b94a
--- a/tests/basic/ec/ec-stripe.t
17b94a
+++ b/tests/basic/ec/ec-stripe.t
17b94a
@@ -202,7 +202,7 @@ TEST truncate -s 0 $B0/test_file
17b94a
 TEST truncate -s 0 $M0/test_file
17b94a
 TEST dd if=$B0/misc_file of=$B0/test_file  bs=1022 count=5  oflag=seek_bytes,sync seek=400 conv=notrunc
17b94a
 TEST dd if=$B0/misc_file of=$M0/test_file  bs=1022 count=5  oflag=seek_bytes,sync seek=400 conv=notrunc
17b94a
-check_statedump_md5sum 4 5
17b94a
+check_statedump_md5sum 4 4
17b94a
 clean_file_unmount
17b94a
 
17b94a
 ### 14 - Truncate to invalidate  all but one the stripe in cache  ####
17b94a
diff --git a/xlators/cluster/ec/src/ec-inode-write.c b/xlators/cluster/ec/src/ec-inode-write.c
17b94a
index ea55140..a45e6d6 100644
17b94a
--- a/xlators/cluster/ec/src/ec-inode-write.c
17b94a
+++ b/xlators/cluster/ec/src/ec-inode-write.c
17b94a
@@ -2013,20 +2013,28 @@ ec_writev_start(ec_fop_data_t *fop)
17b94a
     if (err != 0) {
17b94a
         goto failed_fd;
17b94a
     }
17b94a
+    tail = fop->size - fop->user_size - fop->head;
17b94a
     if (fop->head > 0) {
17b94a
-        found_stripe = ec_get_and_merge_stripe(ec, fop, EC_STRIPE_HEAD);
17b94a
-        if (!found_stripe) {
17b94a
-            if (ec_make_internal_fop_xdata(&xdata)) {
17b94a
-                err = -ENOMEM;
17b94a
-                goto failed_xdata;
17b94a
+        if (current > fop->offset) {
17b94a
+            found_stripe = ec_get_and_merge_stripe(ec, fop, EC_STRIPE_HEAD);
17b94a
+            if (!found_stripe) {
17b94a
+                if (ec_make_internal_fop_xdata(&xdata)) {
17b94a
+                    err = -ENOMEM;
17b94a
+                    goto failed_xdata;
17b94a
+                }
17b94a
+                ec_readv(fop->frame, fop->xl, -1, EC_MINIMUM_MIN,
17b94a
+                         ec_writev_merge_head, NULL, fd, ec->stripe_size,
17b94a
+                         fop->offset, 0, xdata);
17b94a
+            }
17b94a
+        } else {
17b94a
+            memset(fop->vector[0].iov_base, 0, fop->head);
17b94a
+            memset(fop->vector[0].iov_base + fop->size - tail, 0, tail);
17b94a
+            if (ec->stripe_cache && (fop->size <= ec->stripe_size)) {
17b94a
+                ec_add_stripe_in_cache(ec, fop);
17b94a
             }
17b94a
-            ec_readv(fop->frame, fop->xl, -1, EC_MINIMUM_MIN,
17b94a
-                     ec_writev_merge_head, NULL, fd, ec->stripe_size,
17b94a
-                     fop->offset, 0, xdata);
17b94a
         }
17b94a
     }
17b94a
 
17b94a
-    tail = fop->size - fop->user_size - fop->head;
17b94a
     if ((tail > 0) && ((fop->head == 0) || (fop->size > ec->stripe_size))) {
17b94a
         /* Current locking scheme will make sure the 'current' below will
17b94a
          * never decrease while the fop is in progress, so the checks will
17b94a
-- 
17b94a
1.8.3.1
17b94a