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

libglusterfs : Fix crash in glusterd while peer probing

2017-06-20T04:56:08+00:00

glusterd crashes when port is being set explcitly to a
range which is outside greater than short data type range.
Eg. sysctl net.ipv4.ip_local_reserved_ports="49152-49156"
In above case glusterd crashes while parsing the port.

With this fix glusterd will be able to handle port range
between INT_MIN to INT_MAX

> Reviewed-on: https://review.gluster.org/17359
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
>  Reviewed-by: Samikshan Bairagya 
> Reviewed-by: Atin Mukherjee 
> Reviewed-by: Niels de Vos 
> Reviewed-by: Jeff Darcy 

Change-Id: I7c75ee67937b0e3384502973d96b1c36c89e0fe1
BUG: 1459760
Signed-off-by: Gaurav Yadav 
Reviewed-on: https://review.gluster.org/17494
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Samikshan Bairagya 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra Talur

glusterd: Don't spawn new glusterfsds on node reboot with brick-mux

2017-05-30T13:36:40+00:00

With brick multiplexing enabled, upon a node reboot new bricks were
not being attached to the first spawned brick process even though
there wasn't any compatibility issues.

The reason for this is that upon glusterd restart after a node
reboot, since brick services aren't running, glusterd starts the
bricks in a "no-wait" mode. So after a brick process is spawned for
the first brick, there isn't enough time for the corresponding pid
file to get populated with a value before the compatibilty check is
made for the next brick.

This commit solves this by iteratively waiting for the pidfile to be
populated in the brick compatibility comparison stage before checking
if the brick process is alive.

> Reviewed-on: https://review.gluster.org/17307
> Reviewed-by: Atin Mukherjee 
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 

(cherry picked from commit 13e7b3b354a252ad4065f7b2f0f805c40a3c5d18)

Change-Id: Ibd1f8e54c63e4bb04162143c9d70f09918a44aa4
BUG: 1453087
Signed-off-by: Samikshan Bairagya 
Reviewed-on: https://review.gluster.org/17352
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee 
Reviewed-by: Raghavendra Talur

Fixes quota aux mount failure

2017-05-13T21:12:07+00:00

The aux mount is created on the first limit/remove_limit/list command
and it remains until volume is stopped / deleted / (quota is disabled)
, where we do a lazy unmount. If the process is uncleanly terminated,
then the mount entry remains and we get (Transport disconnected) error
on subsequent attempts to run quota list/limit-usage/remove commands.

Second issue, There is also a risk of inadvertent rm -rf on the
/var/run/gluster causing data loss for the user. Ideally, /var/run is
a temp path for application use and should not cause any data loss to
persistent storage.

Solution:
1) unmount the aux mount after each use.
2) clean stale mount before mounting, if any.

One caveat with doing mount/unmount on each command is that we cannot
use same mount point for both list and limit commands.
The reason for this is that list command needs mount to be accessible
in cli after response from glusterd, So it could be unmounted by a
limit command if executed in parallel (had we used same mount point)
Hence we use separate mount points for list and limit commands.

> Reviewed-on: https://review.gluster.org/16938
> NetBSD-regression: NetBSD Build System 
> Smoke: Gluster Build System 
> Reviewed-by: Manikandan Selvaganesh 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Raghavendra G 
> Reviewed-by: Atin Mukherjee 
> (cherry picked from commit 2ae4b4058691b324535d802f4e6d24cce89a10e5)

Change-Id: I4f9e39da2ac2b65941399bffb6440db8a6ba59d0
BUG: 1449779
Signed-off-by: Sanoj Unnikrishnan 
Reviewed-on: https://review.gluster.org/17241
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra Talur

glusterd: Make reset-brick work correctly if brick-mux is on

2017-05-12T19:59:02+00:00

Reset brick currently kills of the corresponding brick process.
However, with brick multiplexing enabled, stopping the brick
process would render all bricks attached to it unavailable. To
handle this correctly, we need to make sure that the brick process
is terminated only if brick-multiplexing is disabled. Otherwise,
we should send the GLUSTERD_BRICK_TERMINATE rpc to the respective
brick process to detach the brick that is to be reset.

> Signed-off-by: Samikshan Bairagya 
> Reviewed-on: https://review.gluster.org/17128
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Atin Mukherjee 

(cherry picked from commit 74383e3ec6f8244b3de9bf14016452498c1ddcf0)

Change-Id: I69002d66ffe6ec36ef48af09b66c522c6d35ac58
BUG: 1449934
Signed-off-by: Samikshan Bairagya 
Reviewed-on: https://review.gluster.org/17253
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee

glusterd: socketfile & pidfile related fixes for brick multiplexing feature

2017-05-10T10:42:05+00:00

Problem: While brick-muliplexing is on after restarting glusterd, CLI is
         not showing pid of all brick processes in all volumes.

Solution: While brick-mux is on all local brick process communicated through one
          UNIX socket but as per current code (glusterd_brick_start) it is trying
          to communicate with separate UNIX socket for each volume which is populated
          based on brick-name and vol-name.Because of multiplexing design only one
          UNIX socket is opened so it is throwing poller error and not able to
          fetch correct status of brick process through cli process.
          To resolve the problem write a new function glusterd_set_socket_filepath_for_mux
          that will call by glusterd_brick_start to validate about the existence of socketpath.
          To avoid the continuous EPOLLERR erros in  logs update socket_connect code.

Test:     To reproduce the issue followed below steps
          1) Create two distributed volumes(dist1 and dist2)
          2) Set cluster.brick-multiplex is on
          3) kill glusterd
          4) run command gluster v status
          After apply the patch it shows correct pid for all volumes

> BUG: 1444596
> Change-Id: I5d10af69dea0d0ca19511f43870f34295a54a4d2
> Signed-off-by: Mohit Agrawal 
> Reviewed-on: https://review.gluster.org/17101
> Smoke: Gluster Build System 
> Reviewed-by: Prashanth Pai 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Atin Mukherjee 
> (cherry picked from commit 21c7f7baccfaf644805e63682e5a7d2a9864a1e6)

Change-Id: I1892c80b9ffa93974f20c92d421660bcf93c4cda
BUG: 1449002
Signed-off-by: Mohit Agrawal 
Reviewed-on: https://review.gluster.org/17210
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee 
Reviewed-by: Prashanth Pai

TIER/TESTS: improving regression test for tier

2017-05-10T06:29:01+00:00

The test files that were marked as bad test were checked and
updated for centos. The tests that had issue were fixed.
Tests that aren't needed anymore are removed.

REASON:

tests/basic/tier/tier-file-create.t
This test checks one line after creating a tiered volume (which
is done in every tier test). So this line is moved along with
other test in tier and the file is deleted.

tests/bugs/tier/bug-1286974.t
This bug checks for the tier as a task and tier has been moved
from a task to service as a part of the tier as a service patch
https://review.gluster.org/#/c/13365/
So it is removed from bad tests.

tests/basic/tier/record-metadata-heat.t
This test had a bug and has been fixed.

tests/basic/tier/bug-1214222-directories_missing_after_attach_tier.t
tests/basic/tier/fops-during-migration.t
tests/basic/tier/tier-snapshot.t
tests/basic/tier/tier_lookup_heal.t

These test seem to work fine on centos now.

>Change-Id: I05537f4bbb91584410177ce43543897eff8761a1
>BUG: 1421600
>Signed-off-by: hari gowtham 
>Reviewed-on: https://review.gluster.org/16605
>Smoke: Gluster Build System 
>Tested-by: hari gowtham 
>NetBSD-regression: NetBSD Build System 
>Reviewed-by: Jeff Darcy 
>CentOS-regression: Gluster Build System 
>Reviewed-by: Raghavendra Talur 

Change-Id: I05537f4bbb91584410177ce43543897eff8761a1
BUG: 1440742
Signed-off-by: hari gowtham 
Change-Id: I9402312608de1ede28009ec52f7385e45678ed75
Reviewed-on: https://review.gluster.org/17027
Tested-by: hari gowtham 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra Talur 
Smoke: Gluster Build System

geo-rep: filter out xtime attribute during getxattr

2017-05-03T09:04:51+00:00

georep gsyncd's xtime needs to filtered irrespective
of any process access.

This way, we can avoid (unnecessarily)syncing xtime attribute
to slave, which may raise permission denied errors.

test case modified to check for xtime xattr only in backend.

Back port of>
>BUG: 1353952
>Signed-off-by: Saravanakumar Arumugam 
>Signed-off-by: Mohammed Rafi KC 
>Reviewed-on: https://review.gluster.org/14880
>Smoke: Gluster Build System 
>Reviewed-by: Kotresh HR 
>Tested-by: Kotresh HR 
>NetBSD-regression: NetBSD Build System 
>CentOS-regression: Gluster Build System 
>Reviewed-by: Pranith Kumar Karampuri 

Change-Id: I2390b703048d5cc747d91fa2ae884dc55de58669
BUG: 1441576
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: https://review.gluster.org/17046
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra Talur

tests: remove tests/bugs/core/bug-1421590-brick-mux-reuse-ports.t

2017-04-27T10:52:53+00:00

bug-1421590-brick-mux-reuse-ports.t seems to be a bad test to me and here is my
reasoning:

This test tries to check if the ports are reused or not. When a volume is
restarted, by the time glusterd tries to allocate a new port to the one of the
brick processes of the volume there is no guarantee that the older port will be
allocated given the kernel might take some extra time to free up the port between
this time frame. From
https://build.gluster.org/job/regression-test-burn-in/2932/console we can
clearly see that post restart of the volume, glusterd allocated port 49153 &
49155 for brick1 & brick2 respectively but the test was expecting the ports to
be matched with 49155 & 49156 which were allocated before the volume was
restarted.

>Reviewed-on: https://review.gluster.org/17033
>Smoke: Gluster Build System 
>NetBSD-regression: NetBSD Build System 
>CentOS-regression: Gluster Build System 
>Reviewed-by: Amar Tumballi 
>(cherry picked from commit 1612355327fa5f86078b9dbcf7a38e4e0c63e205)

Change-Id: Id887bf28445261d4de04fc7502e58057659c9512
BUG: 1445407
Signed-off-by: Atin Mukherjee 
Reviewed-on: https://review.gluster.org/17116
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra Talur

afr: don't do a post-op on a brick if op failed

2017-04-27T10:46:55+00:00

Problem:
In afr-v2, self-blaming xattrs are not there by design. But if the FOP
failed on a brick due to an error other than ENOTCONN (or even due to
ENOTCONN, but we regained connection before postop was wound), we wind
the post-op also on the failed brick, leading to setting self-blaming
xattrs on that brick. This can lead to undesired results like healing of
files in split-brain etc.

Fix:
If a fop failed on a brick on which pre-op was successful, do not
perform post-op on it. This also produces the desired effect of not
resetting the dirty xattr on the brick, which is how it should be
because if the fop failed on a brick, there is no reason to clear the
dirty bit which actually serves as an indication of the failure.

> Reviewed-on: https://review.gluster.org/16976
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Pranith Kumar Karampuri 
(cherry picked from commit 10dad995c989e9d77c341135d7c48817baba966c)

Change-Id: I5f1caf4d1b39f36cf8093ccef940118638caa9c4
BUG: 1443501
Signed-off-by: Ravishankar N 
Reviewed-on: https://review.gluster.org/17083
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri

glusterd: hold off volume deletes while still restarting bricks

2017-04-24T15:49:00+00:00

We need to do this because modifying the volume/brick tree while
glusterd_restart_bricks is still walking it can lead to segfaults.
Without waiting we could accidentally "slip in" while attach_brick has
released big_lock between retries and make such a modification.

Backport of:
> Commit a7ce0548b7969050644891cd90c0bf134fa1594c
> BUG: 1432542
> Reviewed-on: https://review.gluster.org/16927

Change-Id: I30ccc4efa8d286aae847250f5d4fb28956a74b03
BUG: 1441476
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/17044
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee