glusterfs.git/tests/bugs, branch v3.12.7 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>
tests: fix bug-1483058-replace-brick-quorum-validation.t spurious failure 2017-11-30T06:48:06+00:00 Atin Mukherjee amukherj@redhat.com 2017-11-09T17:12:22+00:00 e5db48bf5780c1d278481e0dc25e5c64ccbf9583 > mainline patch : https://review.gluster.org/#/c/18710/ Change-Id: I04c35305bfb663eabbf715eee78695adfd4a2d20 BUG: 1512432 Signed-off-by: Atin Mukherjee <amukherj@redhat.com> (cherry picked from commit 76a83f98b78a0bdf29bbb0f8e4c9ab74dae52be4) 
> mainline patch : https://review.gluster.org/#/c/18710/

Change-Id: I04c35305bfb663eabbf715eee78695adfd4a2d20
BUG: 1512432
Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
(cherry picked from commit 76a83f98b78a0bdf29bbb0f8e4c9ab74dae52be4)
md-cache: avoid checking the xattr value buffer with string functions. 2017-11-09T09:07:06+00:00 Günther Deschner gd@samba.org 2017-10-09T16:02:25+00:00 535d677beabd4d6e06437c386ae80e41ae34f122 xattrs may very well contain binary, non-text data with leading 0 values. Using strcmp for checking empty values is not the appropriate thing to do: In the best case, it might treat a binary xattr value starting with 0 from being cached (and hence also from being reported back with xattr). In the worst case, we might read beyond the end of a data blob that does contain any zero byte. We fix this by checking the length of the data blob and checking the first byte against 0 if the length is one. > Signed-off-by: Guenther Deschner <gd@samba.org> > Pair-Programmed-With: Michael Adam <obnox@samba.org> > Change-Id: If723c465a630b8a37b6be58782a2724df7ac6b11 > BUG: 1476324 > Reviewed-on: https://review.gluster.org/17910 > Reviewed-by: Michael Adam <obnox@samba.org> > Smoke: Gluster Build System <jenkins@build.gluster.org> > Reviewed-by: Poornima G <pgurusid@redhat.com> > Tested-by: Poornima G <pgurusid@redhat.com> > CentOS-regression: Gluster Build System <jenkins@build.gluster.org> > (cherry picked from commit ab4ffdac9dec1867f2d9b33242179cf2b347319d) Change-Id: If723c465a630b8a37b6be58782a2724df7ac6b11 BUG: 1499892 Signed-off-by: Günther Deschner <gd@samba.org> 
xattrs may very well contain binary, non-text data with leading 0
values. Using strcmp for checking empty values is not the appropriate
thing to do: In the best case, it might treat a binary xattr value
starting with 0 from being cached (and hence also from being reported
back with xattr). In the worst case, we might read beyond the end
of a data blob that does contain any zero byte.

We fix this by checking the length of the data blob and checking
the first byte against 0 if the length is one.

> Signed-off-by: Guenther Deschner <gd@samba.org>
> Pair-Programmed-With: Michael Adam <obnox@samba.org>
> Change-Id: If723c465a630b8a37b6be58782a2724df7ac6b11
> BUG: 1476324
> Reviewed-on: https://review.gluster.org/17910
> Reviewed-by: Michael Adam <obnox@samba.org>
> Smoke: Gluster Build System <jenkins@build.gluster.org>
> Reviewed-by: Poornima G <pgurusid@redhat.com>
> Tested-by: Poornima G <pgurusid@redhat.com>
> CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
> (cherry picked from commit ab4ffdac9dec1867f2d9b33242179cf2b347319d)

Change-Id: If723c465a630b8a37b6be58782a2724df7ac6b11
BUG: 1499892
Signed-off-by: Günther Deschner <gd@samba.org>