glusterfs.git/tests/bugs/replicate/bug-1297695.t, branch v3.7.14

cluster/afr: Don't delete gfid-req from lookup request

2016-04-12T11:57:36+00:00

Problem:
Afr does dict_ref of the xattr_req that comes to it and deletes "gfid-req" key.
Dht uses same dict to send lookup to other subvolumes. So in case of
directories and more than 1 dht subvolumes, second subvolume till the last
subvolume won't get a lookup request with "gfid-req". So gfid reset never
happens on the directories in distributed replicate subvolume for 2nd till last
subvolumes.

Fix:
Make a copy of lookup xattr request.

Also fixed replies_wipe possibly resetting gfid to NULL gfid

 >BUG: 1312816
 >Change-Id: Ic16260e5a4664837d069c1dc05b9e96ca05bda88
 >Signed-off-by: Pranith Kumar K 
 >Reviewed-on: http://review.gluster.org/13545
 >Smoke: Gluster Build System 
 >NetBSD-regression: NetBSD Build System 
 >CentOS-regression: Gluster Build System 
 >Reviewed-by: Krutika Dhananjay 
 >(cherry picked from commit 9b022c3a3f2f774904b5b458ae065425b46cc15d)

Change-Id: Ia68193b559ec1dfd841cc5a22ef1fa801b866200
BUG: 1313693
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/13574
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System

cluster/ec: Provide an option to enable/disable eager lock

2016-03-21T05:52:53+00:00

Problem: If a fop takes lock, and completes its operation,
it waits for 1 second before releasing the lock. However,
If ec find any lock contention within this time period,
it release the lock immediately before time expires. As we
take lock on first brick, for few operations, like read, it
might happen that discovery of lock contention might take
long time and can degrades the performance.

Solution: Provide an option to enable/disable eager lock.
If eager lock is disabled, lock will be released as soon
as fop completes.

gluster v set  disperse.eager-lock on
gluster v set  disperse.eager-lock off

master-
http://review.gluster.org/13605

Change-Id: I000985a787eba3c190fdcd5981dfbf04e64af166
BUG: 1318965
Signed-off-by: Ashish Pandey 
Reviewed-on: http://review.gluster.org/13773
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri

cluster/afr: Fix heal-info slow response while IO is in progress

2016-02-05T04:31:54+00:00

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

Now heal-info does an open() on the file being examined so that
the client at some point sees open-fd count being > 1 and releases
the eager-lock so that heal-info doesn't remain blocked forever
until IO completes.

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