glusterfs.git/tests/bugs, branch v3.12.5

cluster/dht: Use percentages for space check

2018-01-12T05:37:34+00:00

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 

Change-Id: I3452520511f304dbf5af86f0632f654a92fcb647
BUG: 1530455
Signed-off-by: N Balachandran

mount/fuse: use fstat in getattr implementation if any opened fd is available

2018-01-02T08:26:42+00:00

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"  for
any security issues with this solution and he approves the solution.

Thanks to "Miklos Szeredi"  for all the
pointers and discussions.

>Change-Id: I88dd29b3607cd2594eee9d72a1637b5346c8d49c
>BUG: 1510401
>Signed-off-by: Raghavendra G 
(cherry picked from commit 8b57378e5596f287a7b9d106dd6fb56a624b42ee)
Change-Id: I88dd29b3607cd2594eee9d72a1637b5346c8d49c
BUG: 1529085
Signed-off-by: Raghavendra G

tests: fix bug-1483058-replace-brick-quorum-validation.t spurious failure

2017-11-30T06:48:06+00:00

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

Change-Id: I04c35305bfb663eabbf715eee78695adfd4a2d20
BUG: 1512432
Signed-off-by: Atin Mukherjee 
(cherry picked from commit 76a83f98b78a0bdf29bbb0f8e4c9ab74dae52be4)

md-cache: avoid checking the xattr value buffer with string functions.

2017-11-09T09:07:06+00:00

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 
> Pair-Programmed-With: Michael Adam 
> Change-Id: If723c465a630b8a37b6be58782a2724df7ac6b11
> BUG: 1476324
> Reviewed-on: https://review.gluster.org/17910
> Reviewed-by: Michael Adam 
> Smoke: Gluster Build System 
> Reviewed-by: Poornima G 
> Tested-by: Poornima G 
> CentOS-regression: Gluster Build System 
> (cherry picked from commit ab4ffdac9dec1867f2d9b33242179cf2b347319d)

Change-Id: If723c465a630b8a37b6be58782a2724df7ac6b11
BUG: 1499892
Signed-off-by: Günther Deschner

glusterd: delete source brick only once in reset-brick commit force

2017-11-02T09:53:37+00:00

While stopping the brick which is to be reset and replaced delete_brick
flag was passed as true which resulted glusterd to free up to source
brick before the actual operation. This results commit force to fail
failing to find the source brickinfo.

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

Change-Id: I1aa7508eff7cc9c9b5d6f5163f3bb92736d6df44
BUG: 1507877
Signed-off-by: Atin Mukherjee 
(cherry picked from commit 0fb8acaa6ff80c43e46deac0ce66b29ae0df0ca4)

glusterd:Marking all the brick status as stopped when a process goes down in brick multiplexing

2017-10-12T18:49:37+00:00

In brick multiplexing environment, if a brick process goes down
i.e., if we kill it with SIGKILL, the status of the brick for which
the process came up for the first time is only changing to stopped.
all other brick statuses are remain started. This is happening because
the process was killed abruptly using SIGKILL signal and signal
handler wasn't invoked and further cleanup wasn't triggered.

When we try to start a volume using force, it shows error saying
"Request timed out", since all the brickinfo->status are still in
started state, we're waiting for one of the brick process to come up
which never going to happen since the brick process was killed.

To resolve this, In the disconnect event, We are checking all the
processes that whether the brick which got disconnected belongs the
process. Once we get the process we are calling a function named
glusterd_mark_bricks_stopped_by_proc() and sending brick_proc_t object as
an argument.

From the glusterd_brick_proc_t we can get all the bricks attached
to that process. but these are duplicated ones. To get the original
brickinfo we are reading volinfo from brick. In volinfo we will have
original brickinfo copies. We are changing brickinfo->status to
stopped for all the bricks.

>Change-Id: Ifb9054b3ee081ef56b39b2903ae686984fe827e7
>BUG: 1499509
>Signed-off-by: Sanju Rakonde 
>Reviewed-on: https://review.gluster.org/#/c/18444/
>Smoke: Gluster Build System 
>CentOS-regression: Gluster Build System 
>Reviewed-by: Atin Mukherjee 
>cherry picked from commit 9422446d72bc054962d72ace9912ecb885946d49)

Change-Id: Ifb9054b3ee081ef56b39b2903ae686984fe827e7
BUG: 1501154
Signed-off-by: Sanju Rakonde

cluster/afr: Make choose-local "reconfigurable"

2017-10-12T18:46:10+00:00

        Backport of:
        > Change-Id: Ibab292ba705d993b475cd0303fb3318211fb2500
        > Reviewed-on: https://review.gluster.org/18026
        > BUG: 1480525
        > cherry-picked from commit 1e2d6537875d16b783e3c50ada7ee61487c6d796

With this change, enabling choose-local (which means its state makes
transition from "off" to "on") will be effective after the first
gfid-lookup on "/" since volume-set was executed.

Change-Id: Ibab292ba705d993b475cd0303fb3318211fb2500
BUG: 1501022
Signed-off-by: Krutika Dhananjay

glusterd: disallow replace brick for dist only volumes

2017-10-12T05:38:57+00:00

Allowing replace-brick on dist only volumes will lead to data loss. This
patch blocks replace brick commit force to fail if a volume is dist
only.

Also removing tests/basic/pump.t as its of no use as per the discussion
in
http://lists.gluster.org/pipermail/gluster-devel/2017-September/053652.html

>Reviewed-on: https://review.gluster.org/18226
>Smoke: Gluster Build System 
>Reviewed-by: N Balachandran 
>CentOS-regression: Gluster Build System 
>(cherry picked from commit 7f70d38b66ce755f848ff0197814457a28b321df)

Change-Id: Iabb0c16f865f3fc361b64a19bfcf0c0fbb5c2682
BUG: 1493975
Signed-off-by: Atin Mukherjee

afr: heal gfid as a part of entry heal

2017-10-10T05:33:15+00:00

Problem:
If a brick crashes after an entry (file or dir) is created but before
gfid is assigned, the good bricks will have pending entry heal xattrs
but the heal won't complete because afr_selfheal_recreate_entry() tries
to create the entry again and it fails with EEXIST.

Fix:
We could have fixed posx_mknod/mkdir etc to assign the gfid if the file
already exists but the right thing to do seems to be to trigger a lookup
on the bad brick and let it heal the gfid instead of winding an
mknod/mkdir in the first place.

(cherry picked from commit 20fa80057eb430fd72b4fa31b9b65598b8ec1265)
Change-Id: I82f76665a7541f1893ef8d847b78af6466aff1ff
BUG: 1499202
Signed-off-by: Ravishankar N

glusterd: fix client io-threads option for replicate volumes

2017-10-09T12:21:08+00:00

Backport of https://review.gluster.org/#/c/18430/

Problem:
Commit ff075a3d6f9b142911d25c27fd209838782bfff0 disabled loading
client-io-threads for replicate volumes (it was set to on by default in
commit e068c1997314046658dd502e9118dab32decf879) due to performance
issues but in doing so, inadvertently failed to load the xlator even if
the user explicitly enabled the option using the volume set command.
This was despite returning returning sucess for the volume set.

Fix:
Modify the check in perfxl_option_handler() and add checks in volume
create/add-brick/remove-brick code paths, tying it all to
GD_OP_VERSION_3_12_2.

Change-Id: Ib612973a999a7da818cc926f5c2601b1f0794fcf
BUG: 1499158
Signed-off-by: Ravishankar N