glusterfs.git/tests/bugs, branch release-4.1

glusterd: add GF_TRANSPORT_BOTH_TCP_RDMA in glusterd_get_gfproxy_client_volfile

2019-06-18T10:43:51+00:00

... with out which volume creation fails with "volume create: : failed:
Failed to create volume files"

>Fixes: bz#1716812
>Change-Id: I2f4c2c6d5290f066b54e1c1db19e25db9937bedb
>Signed-off-by: Atin Mukherjee 

BUG: 1721109
Change-Id: I2f4c2c6d5290f066b54e1c1db19e25db9937bedb
Signed-off-by: Atin Mukherjee

cluster/dht: sync brick root perms on add brick

2019-03-27T05:18:12+00:00

If a single brick is added to the volume and the
newly added brick is the first to respond to a
dht_revalidate call, its stbuf will not be merged
into local->stbuf as the brick does not yet have
a layout. The is_permission_different check therefore
fails to detect that an attr heal is required as it
only considers the stbuf values from existing bricks.
To fix this, merge all stbuf values into local->stbuf
and use local->prebuf to store the correct directory
attributes.

Change-Id: Ic9e8b04a1ab9ed1248b6b056e3450bbafe32e1bc
fixes: bz#1693057
Signed-off-by: N Balachandran

cluster/afr: Send truncate on arbiter brick from SHD

2019-03-21T10:36:15+00:00

Problem:
In an arbiter volume configuration SHD will not send any writes onto the arbiter
brick even if there is data pending marker for the arbiter brick. If we have a
arbiter setup on the geo-rep master and there are data pending markers for the files
on arbiter brick, SHD will not mark any data changelog during healing. While syncing
the data from master to slave, if the arbiter-brick is considered as ACTIVE, then
there is a chance that slave will miss out some data. If the arbiter brick is being
newly added or replaced there is a chance of slave missing all the data during sync.

Fix:
If there is data pending marker for the arbiter brick, send truncate on the arbiter
brick during heal, so that it will record truncate as the data transaction in changelog.

Change-Id: I3242ba6cea6da495c418ef860d9c3359c5459dec
fixes: bz#1687746
Signed-off-by: karthik-us

Revert "libglusterfs/common-utils.c: Fix buffer size for checksum computation"

2019-03-12T07:10:55+00:00

This reverts commit 421b7071f5acee064faf02dc91bcc83efbaa6523.

With this commit, the way glusterd calculates the checksum changes.
In a heterogeneous cluster, upgraded and non-upgraded nodes follow
different mechanisms to compute the checksum. Although the contents
of files are same, we will see checksum mismatch errors and peers
will run into the rejected state.

reverted patch: https://review.gluster.org/#/c/glusterfs/+/22149/

updates: bz#1672249
Change-Id: Ie12e1ac983d62594b161844b2967d8a3fbfedba6
Signed-off-by: Sanju Rakonde

libglusterfs/common-utils.c: Fix buffer size for checksum computation

2019-02-18T14:41:04+00:00

Problem: When quorum count option is updated, the change is not reflected in
the nfs-server.vol file. This is because in get_checksum_for_file(), when the
last part of the file read has size less than buffer size, the read buffer
stores old data value along with correct data value.

Solution: Pass the bytes read instead of fixed buffer size, for calculating
checksum.

Change-Id: I4b641607c8a262961b3f3da0028a54e08c3f8589
fixes: bz#1672249
Signed-off-by: Varsha Rao

Bump up timeout for tests on AWS

2019-02-07T08:06:31+00:00

Fixes: bz#1673265
Change-Id: I2b9be45f199f6436b858536c6f49be85902217f0
Signed-off-by: Nigel Babu

tests: Fix zero-flag.t script

2019-01-03T09:38:16+00:00

The default value of shard-block-size was changed from 4MB
to 64MB sometime back. The script "fallocate"s a 6MB file
and expects it to have 1 shard under .shard. This worked when
the shard-block-size was 4MB. With the default value now at 64MB,
file "file1" won't have any shards under .shard and the stat on the
1st shard's path fails with ENOENT.

Changed the script to explicitly set shard-block-size to 4MB.

Change-Id: I7f1785922287d16d74c95fa57cbbe12e6e66e4f7
fixes: bz#1662635
Signed-off-by: Krutika Dhananjay 
(cherry picked from commit 32f55a2708903145a51de5705ca8e60ff6dd6f9e)

afr: assign gfid during name heal when no 'source' is present

2018-12-03T12:56:09+00:00

Backport of https://review.gluster.org/#/c/glusterfs/+/21297/

Problem:
If parent dir is in split-brain or has dirty xattrs set, and the file
has gfid missing on one of the bricks, then name heal won't assign the
gfid.

Fix:
Use the brick we select the gfid from as the 'source'.

Note: Problem was found while trying to debug a split-brain issue on
Cynthia Zhou's setup.

fixes: bz#1655561
Change-Id: Id088d4f0fb017aa35122de426654194e581ed742
Reported-by: Cynthia Zhou 
Signed-off-by: Ravishankar N

glusterd: ensure volinfo->caps is set to correct value

2018-11-05T20:38:01+00:00

With the commit febf5ed4848, during the volume create op,
we are setting volinfo->caps to 0, only if any of the bricks
belong to the same node and brickinfo->vg[0] is null.
Previously, we used to set volinfo->caps to 0, when
either brick doesn't belong to the same node or brickinfo->vg[0]
is null.

With this patch, we set volinfo->caps to 0, when either brick
doesn't belong to the same node or brickinfo->vg[0] is null.
(as we do earlier without commit febf5ed4848).

> BUG: bz#1635820
> Change-Id: I00a97415786b775fb088ac45566ad52b402f1a49
> Signed-off-by: Sanju Rakonde 

fixes: bz#1643052
Change-Id: I00a97415786b775fb088ac45566ad52b402f1a49
Signed-off-by: Sanju Rakonde

tests: correction in tests/bugs/glusterd/optimized-basic-testcases-in-cluster.t

2018-10-25T13:19:16+00:00

Patch https://review.gluster.org/#/c/glusterfs/+/19135/ has
optimised glusterd test cases by clubbing the similar test
cases into a single test case.

https://review.gluster.org/#/c/glusterfs/+/19135/15/tests/bugs/glusterd/bug-1293414-import-brickinfo-uuid.t
test case has been deleted and added as a part of
tests/bugs/glusterd/optimized-basic-testcases-in-cluster.t

In the original test case, we create a volume with two bricks,
each on a separate node(N1 & N2). From another node in cluster(N3),
we try to detach a node which is hosting bricks. It fails.

In the new test, we created volume with single brick on N1.
and from another node in cluster, we tried to detach N1. we
expect peer detach to fail, but peer detach was success as
the node is hosting all the bricks of volume.

Now, changing the new test case to cover the original test case scenario.

Please refer https://bugzilla.redhat.com/show_bug.cgi?id=1642597#c1 to
understand why the new test case is not failing in centos-regression.

> BUG: bz#1642597

> Change-Id: Ifda12b5677143095f263fbb97a6808573f513234
> Signed-off-by: Sanju Rakonde 
(cherry picked from commit 0ca6773eaf5aeb507ebc72d2c2f61902eeff414c)

fixes: bz#1643075
Change-Id: Ifda12b5677143095f263fbb97a6808573f513234
Signed-off-by: Sanju Rakonde