glusterfs.git/xlators/protocol/client/src/client-rpc-fops.c, branch v3.7.17

protocol/client: Unserialize xdata even if lookup fails

2016-08-24T22:43:17+00:00

Problem: AFR relies on xdata returned by lookup to determine
if there are any files that need healing. This info is further
used to optimize readdirp.

In case of lookups with negative return value, client xlator was
sending NULL xdata. Due to absence of xdata, AFR conservatively
assumes that there are files that need healing, which is incorrect.

Solution: Even in case of unsuccessful lookups, send the xdata
received by protocol client so that higher xlators can get the
info that they rely on.

	>Change-Id: Id3a1023eb536180888eb2c0b39050000b76f7226
	>BUG: 1366284
	>Signed-off-by: Anuradha Talur 
	>Reviewed-on: http://review.gluster.org/15120
	>Smoke: Gluster Build System 
	>Reviewed-by: Poornima G 
	>Tested-by: Poornima G 
	>CentOS-regression: Gluster Build System 
	>NetBSD-regression: NetBSD Build System 
	>Reviewed-by: Ashish Pandey 
	>Reviewed-by: Pranith Kumar Karampuri 
	>Signed-off-by: Anuradha Talur 

Change-Id: Ia22bcb200d599b78677e429d25877c78f7d27612
BUG: 1369211
Signed-off-by: Anuradha Talur 
Reviewed-on: http://review.gluster.org/15259
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Pranith Kumar Karampuri 
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System 
Reviewed-by: Krutika Dhananjay 
CentOS-regression: Gluster Build System

dht/afr/client/posix: Fail mkdir without gfid-req

2016-06-17T06:52:55+00:00

Do not allow directory creations without gfids as
after the directories are created, operations
on them fail anyway. So it is better to fail mkdir.

 >BUG: 1317361
 >Change-Id: I8f8e3b38bbded1960b7215bac0432500f7e78038
 >Signed-off-by: Pranith Kumar K 
 >Reviewed-on: http://review.gluster.org/13690
 >Smoke: Gluster Build System 
 >Reviewed-by: Krutika Dhananjay 
 >CentOS-regression: Gluster Build System 
 >NetBSD-regression: NetBSD Build System 
 >(cherry picked from commit b246b07896fefb261c9fb07f3f29f0d03b81b88d)

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

protocol/client: Don't change op_ret when xdata_rsp is present

2016-03-02T07:22:16+00:00

 >Change-Id: Ia69cc420ad7b5766d513ea2715bbca50d8d57132
 >BUG: 1312226
 >Signed-off-by: Pranith Kumar K 
 >Reviewed-on: http://review.gluster.org/13530
 >Smoke: Gluster Build System 
 >CentOS-regression: Gluster Build System 
 >Reviewed-by: Raghavendra Talur 
 >NetBSD-regression: NetBSD Build System 
 >Reviewed-by: Jeff Darcy 
 >(cherry picked from commit 1f673d141fb06282583175357348a7a2fc19e604)

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

geo-rep: Don't log geo-rep safe errors in mount logs

2015-11-23T19:10:41+00:00

ENOENT is a safe error for geo-replication in case of
rm -rf. RMDIR is recorded in changelog of each brick,
geo-rep processes all changelogs among which one will
succeed and rest will get ENOENT which can be ignored.
Similarly ENOENT can also be ignored in case of all
unlink operation during changelog replay that can
happen when worker goes down and comes back.

Change-Id: I6756f8f4c3fce7a159751a2bfce891ff16ad31a4
BUG: 1283473
Signed-off-by: Kotresh HR 
Reviewed-on: http://review.gluster.org/11833
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Aravinda VK 
Reviewed-by: Milind Changire 
Reviewed-by: Saravanakumar Arumugam 
Reviewed-by: Venky Shankar 
 (cherry picked from commit a52fd2cb7fa3aaff74461f58f32f4ff0b8e0904d)
Reviewed-on: http://review.gluster.org/12651
Reviewed-by: Vijay Bellur

protocol/client: give preference to loc->gfid over inode->gfid

2015-10-13T11:26:35+00:00

Backport of review.gluster.org/#/c/12233/

There are xlators which perform fops even before inode gets linked. Because of this loc.gfid is preferred at the time of inodelk/entrylk but by the time unlock can happen, inode could be linked with a different gfid than the one in loc.gfid (because of the way dht was giving preference) Due to this unlock goes on a different inode than the one we sent inodelk on, which leads to hang.

Credits to Pranith for the fix.

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

logging: client3_3_removexattr_cbk should not log expected ENODATA

2015-07-26T08:10:24+00:00

Commit 379dbbfd changed the log level of an expected error message from
GF_LOG_DEBUG to '0'. This causes the message to always get logged. It is
intended to log the warning when the xattr could not be removed (but
exists), removing a non-existing xattr is sufficient as debug.

Backported from:
> BUG: 1246736
> Change-Id: If11d15d699e8152cc32e0c0c1d65b587c5c48892
> Reviewed-on: http://review.gluster.org/11759
> Signed-off-by: Niels de Vos 

Change-Id: If11d15d699e8152cc32e0c0c1d65b587c5c48892
BUG: 1246728
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/11760
Tested-by: NetBSD Build System 
Reviewed-by: Joe Julian 
Tested-by: Joe Julian 
Tested-by: Gluster Build System

protocol/client : removing duplicate printing in gf_msg

2015-06-27T12:04:47+00:00

Since the 3rd and 5th argument of gf_msg framework
prints the error string in case of strerror(),
the 5th argument is removed.

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

Cherry picked from commit 4acd9d1bfc2be5179ddb611f61afaaeaa15be2cb
> Change-Id: Ib1794ea2d4cb5c46a39311f0afcfd7e494540506
> BUG: 1194640
> Signed-off-by: Manikandan Selvaganesh 
> Reviewed-on: http://review.gluster.org/11280
> Tested-by: NetBSD Build System 
> Reviewed-by: Raghavendra Bhat 
> Reviewed-by: Vijay Bellur 

Change-Id: Ib1794ea2d4cb5c46a39311f0afcfd7e494540506
BUG: 1217722
Signed-off-by: Manikandan Selvaganesh 
Reviewed-on: http://review.gluster.org/11374
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

protocol/client : porting log messages to new framework

2015-06-17T12:11:43+00:00

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

Cherry picked from 379dbbfd683d2b0e1704c098b1f020567328122c
> Change-Id: I9bf2ca08fef969e566a64475d0f7a16d37e66eeb
> BUG: 1194640
> Signed-off-by: Manikandan Selvaganesh 
> Reviewed-on: http://review.gluster.org/10042
> Tested-by: Gluster Build System 
> Reviewed-by: Raghavendra G 
> Tested-by: Raghavendra G 

Change-Id: I9bf2ca08fef969e566a64475d0f7a16d37e66eeb
BUG: 1217722
Signed-off-by: Manikandan Selvaganesh 
Reviewed-on: http://review.gluster.org/11240
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

logging: log "Stale filehandle" on the client as Debug

2015-06-14T06:35:58+00:00

There are valid use-cases where a "Stale filehandle" is expected. One of
these is deleting a file through NFS-Ganesha. When the "filename" is
deleted, Ganesha will stat the file-handle to update its attributes. The
file-handle would still be valid in the case where there are hardlinks.

There is no need to log "Stale filehandle" as Warning. It is perfectly
fine to have this logged as Debug.

Cherry picked from commit ec7d0c3de11cbee1470308dcc10ec9f02e7fdfff:
> Change-Id: Ib9006d95a5d1f7dd394bf5d5994ad70740ad4ab2
> BUG: 1228731
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/11107
> Reviewed-by: Kaleb KEITHLEY 
> Tested-by: Gluster Build System 
> Reviewed-by: soumya k 
> Reviewed-by: jiffin tony Thottan 

Change-Id: Ib9006d95a5d1f7dd394bf5d5994ad70740ad4ab2
BUG: 1228729
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/11169
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

geo-rep: ignore symlink and harlink errors in geo-rep

2015-06-13T09:23:07+00:00

Ignore logging in case of symlink and hardlink creation
errors, as these are safe errors with respect to
geo-replication.

Change-Id: I3b863fb03ae23dbea907e4dd9477ff85feecad70
BUG: 1225574
Signed-off-by: Saravanakumar Arumugam 
Reviewed-on: http://review.gluster.org/10957
Reviewed-on: http://review.gluster.org/10984
Reviewed-by: Vijay Bellur 
Tested-by: Vijay Bellur