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

cluster/afr: Fix data loss due to race between sh and ongoing write.

2016-01-29T01:43:33+00:00

        Backport of: http://review.gluster.org/#/c/13001/

Problem:

When IO is happening on a file and a brick goes down comes back up
during this time, protocol/client translator attempts reopening of the
fd on the gfid handle of the file. But if another client renames this
file while a brick was down && writes were in progress on it, once this
brick is back up, there can be a race between reopening of the fd and
entry self-heal replaying the effect of the rename() on the sink brick.
If the reopening of the fd happens first, the application's writes
continue to go into the data blocks associated with the gfid.
Now entry-self-heal deletes 'src' and creates 'dst' file on the sink,
marking dst as a 'newentry'.  Data self-heal is also completed on 'dst'
as a result and self-heal terminates. If at this point the application
is still writing to this fd, all writes on the file after self-heal
would go into the data blocks associated with this fd, which would be
lost once the fd is closed. The result - the 'dst' file on the source
and sink are not the same and there is no pending heal on the file,
leading to silent corruption on the sink.

Fix:

Leverage http://review.gluster.org/#/c/12816/ to ensure the gfid handle
path gets saved in .glusterfs/unlink until the fd is closed on the file.
During this time, when self-heal sends mknod() with gfid of the file,
do the following:
link() the gfid handle under .glusterfs/unlink to the new path to be
created in mknod() and
rename() the gfid handle to go back under .glusterfs/ab/cd/.


Change-Id: I5dc49c127ef0a1bf3cf4ce1b24610b1527f84d6f
BUG: 1293265
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/13036
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Pranith Kumar Karampuri 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

features/bitrot: add check for corrupted object in f{stat}

2016-01-27T02:44:58+00:00

         Backport of http://review.gluster.org/13120

Check for corrupted objects is done bt bitrot stub component
for data operations and such fops are denied processing by
returning EIO. These checks were not done for operations such
as get/set extended attribute, stat and the likes - IOW, stub
only blocked pure data operations.

However, its necessary to have these checks for certain other
fops, most importantly stat (and fstat). This is due to the
fact that clients could possibly get stale stat information
(such as size, {a,c,m}time) resulting in incorrect operation
of the application that rely on these fields. Note that, the
data that replication would take care of fetching good (and
correct) data, but the staleness of stat information could
lead to data inconsistencies (e.g., rebalance, tier).

Change-Id: I5a22780373b182a13f8d2c4ca6b7d9aa0ffbfca3
BUG: 1297213
Signed-off-by: Venky Shankar 
Reviewed-on: http://review.gluster.org/13276
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Pranith Kumar Karampuri 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

features/shard: Implement fallocate FOP

2016-01-22T05:31:59+00:00

        Backport of: http://review.gluster.org/13196


Change-Id: Iab0c41319af42210c871a3ed6cf52a987c5d88d7
BUG: 1299712
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/13259
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Pranith Kumar Karampuri 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

glusterd: import/export brickinfo->uuid

2016-01-14T09:35:05+00:00

Backport of http://review.gluster.org/#/c/13047/ 

    Given a two node cluster with node N1 & N2, if a dummy node N3 is peer probed, the
    probed node N3  goes for importing volumes from the probing node (N1), but
    it still doesn't have information about the other node (N2) about its membership
    (since peer update happens post volume updates) and hence fail to update its
    brick's uuid. Post that even though N2 updates N3 about its membership the
    brick's uuid was never generated. Now as a consequence when N3 initiates a
    detach of N2, it checks whether the node to be detached has any bricks
    configured by its respective uuid which is NULL in this case and hence it goes
    ahead and removes the peer which ideally it shouldn't have (refer to
    glusterd_friend_contains_vol_bricks () for the logic)
    
    Fix is to export brick's uuid and import it at the probed node instead of
    resolving it.

Change-Id: I2d88c72175347550a45ab12aff0ae248e56baa87
BUG: 1297305
Signed-off-by: Atin Mukherjee 
Reviewed-on: http://review.gluster.org/13047
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Gaurav Kumar Garg 
Reviewed-by: Avra Sengupta 
Reviewed-on: http://review.gluster.org/13210

quota: handle quota xattr removal when quota is enabled again

2016-01-07T08:20:36+00:00

This is a backport of http://review.gluster.org/#/c/13065/

When a quota is disable and enabled again before completing
the cleanup operation, this can remove the new xattrs
and quota accounting can become wrong

Remove removing the xattr, check if quota enabled again and the
xattr is new

> Change-Id: Idda216f1e7346a9b843dbc112ea3e6faa9c47483
> BUG: 1293601
> Signed-off-by: vmallika 

Change-Id: Ia9e3002229427f811d6a35eabf21541f4fa057af
BUG: 1294609
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/13109
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

tests/tier: spurious failure in rename test

2015-12-21T13:28:51+00:00

bug-1279376-rename-demoted-file.t fails sometimes
The fix is based on the assumption that the test
failed because the demotion happened too quickly.

Change-Id: I7fa9f511c96aa2bc00e4d41d479f67018d369329
BUG: 1291046
Signed-off-by: N Balachandran 
Reviewed-on: http://review.gluster.org/12958
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Dan Lambright 
Tested-by: Dan Lambright

tests:bugs:fuse: add test for bug #1283103 - selinux mount vs security xattrs

2015-12-17T12:06:06+00:00

> BUG: 1283103
> Change-Id: Ic4485d650275f67eb6b0b8382a92eb829c06e27c
> Signed-off-by: Michael Adam 
> Reviewed-on: http://review.gluster.org/12827
> Tested-by: Gluster Build System 
> Reviewed-by: Niels de Vos 
> Reviewed-by: Raghavendra G 

(cherry picked from commit 8df88683c334c0652770e8e0fcec59dbc8bb5748)

Change-Id: I6b8e6f1c295ab951e29519113b39c7d7e75b90ee
BUG: 1283107
Signed-off-by: Michael Adam 
Reviewed-on: http://review.gluster.org/12954
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

glusterd/afr: store afr pending xattrs as a volume option

2015-12-17T06:02:55+00:00

Backport of http://review.gluster.org/#/c/12738/

Problem:
When AFR xlator initialises, it uses the name of the client xlators
below it for storing the pending changelogs (xattrs). This can be
problem when some other xlator is loaded in between AFR and the client.
Though that is a trivial 'traverse-graph-till-the-client-and-use-the-name'
fix in AFR's init(), there are other issues like when there's no client
xlator at all when, say, AFR is moved to the server side.

Fix:
The client xlator names are currenly unique and stored as
brickinfo->brick_ids. So persist these ids as comma separated values in
AFR's volume_options and use them as xattr values during init().

Change-Id: Ie761ffeb3373a4c4d85ad05c84a768c4188aa90d
BUG: 1291985
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/12977
Tested-by: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System

tests, shard: Remove dependency on strict-write-ordering

2015-12-15T08:34:26+00:00

        Backport of: http://review.gluster.org/#/c/12915/

Change-Id: I11968c32e57f73589e442fa13391f922fa4bbf2a
BUG: 1290655
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/12946
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System

tier/glusterd: Check before starting tier daemon during volume start

2015-12-11T18:52:14+00:00

We start tier daemon when volume is started without looking into the
previous status. The problem with that if detach-tier is started
and then volume force start is actually starting tier daemon.

This is also fixes a problem where tier daemon is not starting
after detach stop.

Back port of>
>Change-Id: I15b56a711e12f0e24f5ab123561258bd448621f7
>BUG: 1286974
>Signed-off-by: Mohammed Rafi KC 
>Reviewed-on: http://review.gluster.org/12833
>Tested-by: NetBSD Build System 
>Tested-by: Gluster Build System 
>Reviewed-by: Atin Mukherjee 

(cherry picked from commit 28da53e26e88f23f8917810ce0177f2628aa7e9a)

Change-Id: I22c9ad0b2bc4488c15978d8bf85d05113e8b886e
BUG: 1289898
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/12921
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Dan Lambright