glusterfs.git/tests, branch v3.12.7 cluster/afr: Fail open on split-brain 2018-03-08T06:39:57+00:00 Pranith Kumar K pkarampu@redhat.com 2017-09-04T11:27:25+00:00 e304d218602f3099dc4ba9bb86fd953cee8a8e59 Problem: Append on a file with split-brain succeeds. Open is intercepted by open-behind, when write comes on the file, open-behind does open+write. Open succeeds because afr doesn't fail it. Then write succeeds because write-behind intercepts it. Flush is also intercepted by write-behind, so the application never gets to know that the write failed. Fix: Fail open on split-brain, so that when open-behind does open+write open fails which leads to write failure. Application will know about this failure. Change-Id: I4bff1c747c97bb2925d6987f4ced5f1ce75dbc15 BUG: 1544635 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com> (cherry picked from commit 786343abca3474ff01aa1017210112d97cbc4843) 
Problem:
Append on a file with split-brain succeeds. Open is intercepted by open-behind,
when write comes on the file, open-behind does open+write. Open succeeds
because afr doesn't fail it. Then write succeeds because write-behind
intercepts it. Flush is also intercepted by write-behind, so the application
never gets to know that the write failed.

Fix:
Fail open on split-brain, so that when open-behind does open+write open fails
which leads to write failure. Application will know about this failure.

Change-Id: I4bff1c747c97bb2925d6987f4ced5f1ce75dbc15
BUG: 1544635
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
(cherry picked from commit 786343abca3474ff01aa1017210112d97cbc4843)
tests/dht: Non-root can delete stale linkto files 2018-02-12T10:13:57+00:00 N Balachandran nbalacha@redhat.com 2018-02-07T15:25:47+00:00 9436976cb1971f7426ba55f28f81bac294170f90 Test to check that non-root users can delete stale linkto files > Change-Id: Ic9bc76bc485cab839927af60cfce78a058eee2e4 > BUG: 1542318 > Signed-off-by: N Balachandran <nbalacha@redhat.com> Change-Id: Ic9bc76bc485cab839927af60cfce78a058eee2e4 BUG: 1543016 Signed-off-by: N Balachandran <nbalacha@redhat.com> 
Test to check that non-root users can delete stale
linkto files

> Change-Id: Ic9bc76bc485cab839927af60cfce78a058eee2e4
> BUG: 1542318
> Signed-off-by: N Balachandran <nbalacha@redhat.com>

Change-Id: Ic9bc76bc485cab839927af60cfce78a058eee2e4
BUG: 1543016
Signed-off-by: N Balachandran <nbalacha@redhat.com>
nfs: Fixing the failure in bug-974972.t test case 2018-02-12T10:13:32+00:00 karthik-us ksubrahm@redhat.com 2018-02-08T09:17:34+00:00 23dd9f8127bd591868cd2e31e72e72b6bd3c3803 Problem: gNFS servers is restarted even before the pending marker is set becuase of eager lock being on, leading to a file in split-brain to get healed. Fix: Switch off the eager lock. This is fixed in the later versions by the patch: https://review.gluster.org/#/c/13075/ Change-Id: If59e5ede2de1cbfcdeac01cca38dc0d046f1993c BUG: 1542475 Signed-off-by: karthik-us <ksubrahm@redhat.com> 
Problem:
gNFS servers is restarted even before the pending marker is set
becuase of eager lock being on, leading to a file in split-brain
to get healed.

Fix:
Switch off the eager lock.
This is fixed in the later versions by the patch:
https://review.gluster.org/#/c/13075/

Change-Id: If59e5ede2de1cbfcdeac01cca38dc0d046f1993c
BUG: 1542475
Signed-off-by: karthik-us <ksubrahm@redhat.com>
tests: mark test bad 2018-02-07T06:10:46+00:00 N Balachandran nbalacha@redhat.com 2018-02-07T06:08:30+00:00 e19b3354a173b3e4d652a9aca5cc066eccc08332 Please remove after fixing the test. Change-Id: If6c36dc6c395730dfb17b5b4df6f24629d904926 BUG: 1542826 Signed-off-by: N Balachandran <nbalacha@redhat.com> 
Please remove after fixing the test.

Change-Id: If6c36dc6c395730dfb17b5b4df6f24629d904926
BUG: 1542826
Signed-off-by: N Balachandran <nbalacha@redhat.com>
tests: Spurious failure multiplex-limit-issue-151.t 2018-02-06T16:34:25+00:00 N Balachandran nbalacha@redhat.com 2017-11-27T16:48:33+00:00 b94e8c60dff6284ad30ee1b2a96e4a3221768a4d A timing issue caused the remove-brick commit to fail. Replaced 'remove-brick commit' with 'remove-brick force'. > Change-Id: I69144b2f7be34095dbd3a7d182e0bf01b27fb0a4 > BUG: 1517904 > Signed-off-by: N Balachandran <nbalacha@redhat.com> Change-Id: I69144b2f7be34095dbd3a7d182e0bf01b27fb0a4 BUG: 1542615 Signed-off-by: N Balachandran <nbalacha@redhat.com> 
A timing issue caused the remove-brick commit to fail.
Replaced 'remove-brick commit' with 'remove-brick force'.

> Change-Id: I69144b2f7be34095dbd3a7d182e0bf01b27fb0a4
> BUG: 1517904
> Signed-off-by: N Balachandran <nbalacha@redhat.com>

Change-Id: I69144b2f7be34095dbd3a7d182e0bf01b27fb0a4
BUG: 1542615
Signed-off-by: N Balachandran <nbalacha@redhat.com>
tests: Fix a broken test case 2018-02-05T13:29:58+00:00 Poornima G pgurusid@redhat.com 2017-11-29T12:54:23+00:00 4389b4fd93b85814c950aeafbeda59538b70414d Issue: When using statedump command to take statedump of the gfapi process, we specify the following things: $gluster volume statedump <volname> client <host>:<pid> pid: Pid of the gfapi application host: This should be the IP/hostname as seen by the glusterd, the gfapi application is connected to. In this test case, if gfapi application is running locally, and is connected to $H1 glusterd, the <host> need not be $H1. <host> could be localhost, 127.0.0.1, 127.1.1.1 etc. based on the configuration of the system. Hence use netstat to find the right <host> value. >mainline patch : https://review.gluster.org/#/c/18893/ Change-Id: I6efb9d1ccaf9c6841a9ab7c9ebfecafc03c0bc5e BUG: 1542054 Signed-off-by: Poornima G <pgurusid@redhat.com> 
Issue: When using statedump command to take statedump of the
gfapi process, we specify the following things:

$gluster volume statedump <volname> client <host>:<pid>
   pid: Pid of the gfapi application
   host: This should be the IP/hostname as seen by the glusterd,
         the gfapi application is connected to.

In this test case, if gfapi application is running locally,
and is connected to $H1 glusterd, the <host> need not be $H1.
<host> could be localhost, 127.0.0.1, 127.1.1.1 etc. based on
the configuration of the system. Hence use netstat to find the
right <host> value.

>mainline patch : https://review.gluster.org/#/c/18893/

Change-Id: I6efb9d1ccaf9c6841a9ab7c9ebfecafc03c0bc5e
BUG: 1542054
Signed-off-by: Poornima G <pgurusid@redhat.com>
cluster/ec: OpenFD heal implementation for EC 2018-02-02T06:50:35+00:00 Sunil Kumar Acharya sheggodu@redhat.com 2017-03-23T07:20:41+00:00 b5a8e10a2aa80be463e1d20f4099d24294bc5e8a Existing EC code doesn't try to heal the OpenFD to avoid unnecessary healing of the data later. Fix implements the healing of open FDs before carrying out file operations on them by making an attempt to open the FDs on required up nodes. Backport of: >BUG: 1431955 BUG: 1536334 Change-Id: Ib696f59c41ffd8d5678a484b23a00bb02764ed15 Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com> 
Existing EC code doesn't try to heal the OpenFD to
avoid unnecessary healing of the data later.

Fix implements the healing of open FDs before
carrying out file operations on them by making an
attempt to open the FDs on required up nodes.

Backport of:
>BUG: 1431955

BUG: 1536334
Change-Id: Ib696f59c41ffd8d5678a484b23a00bb02764ed15
Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
posix: delete stale gfid handles in nameless lookup 2018-01-16T04:54:21+00:00 Ravishankar N ravishankar@redhat.com 2018-01-16T04:46:41+00:00 9197ed135dc07b6db61dc628bd1d87eb6db5eaa0 ..in order for self-heal of symlinks to work properly (see BZ for details). Backport of https://review.gluster.org/#/c/19070/ Signed-off-by: Ravishankar N <ravishankar@redhat.com> Change-Id: I9a011d00b07a690446f7fd3589e96f840e8b7501 BUG: 1534847 
..in order for self-heal of symlinks to work properly (see BZ for
details).

Backport of https://review.gluster.org/#/c/19070/
Signed-off-by: Ravishankar N <ravishankar@redhat.com>

Change-Id: I9a011d00b07a690446f7fd3589e96f840e8b7501
BUG: 1534847
cluster/dht: Use percentages for space check 2018-01-12T05:37:34+00:00 N Balachandran nbalacha@redhat.com 2017-12-28T05:53:29+00:00 19b74478fc87909b95a6c87ab212f21b79c809f3 With heterogenous bricks now being supported in DHT we could run into issues where files are not migrated even though there is sufficient space in newly added bricks which just happen to be considerably smaller than older bricks. Using percentages instead of absolute available space for space checks can mitigate that to some extent. Marking bug-1247563.t as that used to depend on the easier code to prevent a file from migrating. This will be removed once we find a way to force a file migration failure. > Change-Id: I3452520511f304dbf5af86f0632f654a92fcb647 > BUG: 1529440 > Signed-off-by: N Balachandran <nbalacha@redhat.com> Change-Id: I3452520511f304dbf5af86f0632f654a92fcb647 BUG: 1530455 Signed-off-by: N Balachandran <nbalacha@redhat.com> 
With heterogenous bricks now being supported in DHT
we could run into issues where files are not migrated
even though there is sufficient space in newly added bricks
which just happen to be considerably smaller than older
bricks. Using percentages instead of absolute available
space for space checks can mitigate that to some extent.

Marking bug-1247563.t as that used to depend on the easier
code to prevent a file from migrating. This will be removed
once we find a way to force a file migration failure.

> Change-Id: I3452520511f304dbf5af86f0632f654a92fcb647
> BUG: 1529440
> Signed-off-by: N Balachandran <nbalacha@redhat.com>

Change-Id: I3452520511f304dbf5af86f0632f654a92fcb647
BUG: 1530455
Signed-off-by: N Balachandran <nbalacha@redhat.com>
mount/fuse: use fstat in getattr implementation if any opened fd is available 2018-01-02T08:26:42+00:00 Raghavendra G rgowdapp@redhat.com 2017-11-07T10:39:37+00:00 2c1cc19992edfc4ac0402fe96ca0925933566b89 The restriction of using fds opened by the same Pid means fds cannot be shared across threads of multithreaded application. Note that fops from kernel have different Pid for different threads. Imagine following sequence of operations: * Turn off performance.open-behind * Thread t1 opens an fd - fd1 - on file "file". Let's assume nodeid of "file" is "nodeid-file". * Thread t2 does RENAME ("newfile", "file"). Let's assume nodeid of "newfile" as "nodeid-newfile". * t2 proceeds to do fstat (fd1) The above set of operations can sometimes result in ESTALE/ENOENT errors. RENAME overwrites "file" with "newfile" changing its nodeid from "nodeid-file" to "nodeid-newfile" and post RENAME, "nodeid-file" is removed from the backend. If fstat carries nodeid-file as argument, which can happen if lookup has not refreshed the nodeid of "file" and since t2 doesn't have an fd opened, fuse_getattr_resume uses STAT which will fail as "nodeid-file" no longer exists. Since the above set of operations and sharing of fds across multiple threads are valid, this is a bug. The fix is to use any fd opened on the inode. In this specific example fuse_getattr_resume will find fd1 and winds down the call as fstat (fd1) which won't fail. Cross-checked with "Miklos Szeredi" <mszeredi.at.redhat.dot.com> for any security issues with this solution and he approves the solution. Thanks to "Miklos Szeredi" <mszeredi.at.redhat.dot.com> for all the pointers and discussions. >Change-Id: I88dd29b3607cd2594eee9d72a1637b5346c8d49c >BUG: 1510401 >Signed-off-by: Raghavendra G <rgowdapp@redhat.com> (cherry picked from commit 8b57378e5596f287a7b9d106dd6fb56a624b42ee) Change-Id: I88dd29b3607cd2594eee9d72a1637b5346c8d49c BUG: 1529085 Signed-off-by: Raghavendra G <rgowdapp@redhat.com> 
The restriction of using fds opened by the same Pid means fds cannot
be shared across threads of multithreaded application. Note that fops
from kernel have different Pid for different threads. Imagine
following sequence of operations:

* Turn off performance.open-behind
* Thread t1 opens an fd - fd1 - on file "file". Let's assume nodeid of
  "file" is "nodeid-file".
* Thread t2 does RENAME ("newfile", "file"). Let's assume nodeid of
  "newfile" as "nodeid-newfile".
* t2 proceeds to do fstat (fd1)

The above set of operations can sometimes result in ESTALE/ENOENT
errors. RENAME overwrites "file" with "newfile" changing its nodeid
from "nodeid-file" to "nodeid-newfile" and post RENAME, "nodeid-file" is
removed from the backend. If fstat carries nodeid-file as argument,
which can happen if lookup has not refreshed the nodeid of "file" and
since t2 doesn't have an fd opened, fuse_getattr_resume uses STAT
which will fail as "nodeid-file" no longer exists.

Since the above set of operations and sharing of fds across
multiple threads are valid, this is a bug.

The fix is to use any fd opened on the inode. In this specific example
fuse_getattr_resume will find fd1 and winds down the call as fstat
(fd1) which won't fail.

Cross-checked with "Miklos Szeredi" <mszeredi.at.redhat.dot.com> for
any security issues with this solution and he approves the solution.

Thanks to "Miklos Szeredi" <mszeredi.at.redhat.dot.com> for all the
pointers and discussions.

>Change-Id: I88dd29b3607cd2594eee9d72a1637b5346c8d49c
>BUG: 1510401
>Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
(cherry picked from commit 8b57378e5596f287a7b9d106dd6fb56a624b42ee)
Change-Id: I88dd29b3607cd2594eee9d72a1637b5346c8d49c
BUG: 1529085
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>