glusterfs.git/xlators, branch v3.4.7beta3

protocol: Log ENODATA & ENOATTR logs at DEBUG loglevel in removexattr_cbk

2015-03-25T17:13:02+00:00

Prevents messages of the following type from being seen by default in
the log files:

[2014-09-19 07:57:39.877806] W
[client-rpc-fops.c:1232:client3_3_removexattr_cbk] 0--client-0:
remote operation failed: No data available
[2014-09-19 07:57:39.877963] W
[client-rpc-fops.c:1232:client3_3_removexattr_cbk] 0--client-1:
remote operation failed: No data available

Backport of http://review.gluster.org/#/c/8781/, see BZ 1144527

Change-Id: I814e12c56f5b95fcc24a6f0d46c7240d7abd16e4
BUG: 1205715
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/9996
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

cluster/dht: set op_errno correctly during migration.

2015-03-05T21:38:22+00:00

Backport of, http://review.gluster.org/#/c/6219/6

Change-Id: Ic3419dd05b4dbe49b6adf5648bdbe137722a6d04
BUG: 1166278
Signed-off-by: Shyam 
Reviewed-on: http://review.gluster.org/9599
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Niels de Vos

cluster/dht: Fixed double UNWIND in lookup everywhere code

2015-03-03T18:35:35+00:00

backport of http://review.gluster.org/#/c/8666/2 on master

In dht_lookup_everywhere_done:
At line 1107 we call DHT_STACK_UNWIND
and in the same if condition we go ahead and call, goto
unwind_hashed_and_cached; which at Line 1371 calls another UNWIND.

As is obvious, higher frames could cleanup their locals and on
receiving the next unwind could cause a coredump of the process.

Fixed the same by calling the required return post the first unwind

Change-Id: I4629680af7ebecd9828941d883e33fb6e43d9703
BUG: 1151397
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/9765
Tested-by: Gluster Build System 
Reviewed-by: Venky Shankar 
Reviewed-by: Shyamsundar Ranganathan

cluster/afr: Handle EAGAIN properly in inodelk

2014-10-30T14:18:27+00:00

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

Problem:
When one of the brick is taken down and brough back up in a replica pair, locks
on that brick will be allowed. Afr returns inodelk success even when one of the
bricks already has the lock taken.

Fix:
If any brick returns EAGAIN return failure to parent xlator.

Note: This change only works for non-blocking inodelks. This patch addresses
dht-synchronization which uses non-blocking locks for rename. Blocking lock is
issued by only one of the rebalance processes. So for now there is no
possibility of deadlock.

BUG: 1151308
Change-Id: I72f15d8789442c29b5c7be2d5dabf7bae6bfa845
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8923
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos 
Reviewed-by: Kaleb KEITHLEY

Cluster/DHT: Changing rename log severity

2014-10-20T14:56:16+00:00

Changing log level for a rename message from debug
to info to improve debuggability

Change-Id: I53031fcf97fffd62095692477330ecde0cf47dcd
BUG: 1139998
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8582
Reviewed-by: Vijay Bellur 
Tested-by: Gluster Build System 
Reviewed-on: http://review.gluster.org/8685
Reviewed-by: Kaleb KEITHLEY

cluster/dht: Rename should not fail post hardlink creation

2014-10-20T14:56:00+00:00

In the rename path, we wind the creation of newname hardlink and
linkto file in dst hashed a the same time. If the linkto creation
fails, but the link creation succeeds, we enter the failure code
and cleanup the created newname hardlink.

In the interim if another client looks up newname and finds it as
a hardlink from FUSE, it could send an unlink for oldname instead
of a rename. This combined with the above cleanup code could end
up losing all the files copies, and thereby losing data.

This fix separates these steps into 2 parts, creating the linkto
first and then the link file, so that post link file creation no
failures would cleanup the newname file. If linkto fails then link
is not attempted, thereby not polluting the name space with
newname.

Change-Id: I61da8e906060da16a31ea1076eec2f01fd617f44
BUG: 1139998
Signed-off-by: Shyam 
Reviewed-on: http://review.gluster.org/8570
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8683
Reviewed-by: Kaleb KEITHLEY

cluster/dht: Treat linkto file rename failure as non-critial error

2014-10-20T14:55:49+00:00

It is a critical failure iff we fail to rename the cached file
if the rename of the linkto failed, it is not a critical failure,
and we do not want to lose the created hard link for the new
name as that could have been read by other clients.

NOTE: If another client is attempting the same oldname -> newname
rename, and finds both file names as existing, and are hard links
to each other, then FUSE would send in an unlink for oldname. In
this time duration if we treat the linkto as a critical error and
unlink the newname we created, we would have effectively lost the
file to rename operations.

Repercussions of treating this as a non-critical error is that
we could leave behind a stale linkto file and/or not create the new
linkto file, the second case would be rectified by a subsequent
lookup, the first case by a rebalance, like for all stale linkto
files

Change-Id: Ia53ad8b43c3cf8f48ef5b43fd1fec4274e807556
BUG: 1139998
Signed-off-by: Shyam 
Reviewed-on: http://review.gluster.org/8563
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8682
Reviewed-by: Kaleb KEITHLEY

cluster/dht: synchronize rename and file-migration

2014-10-20T14:55:36+00:00

Change-Id: I4f243c946f76d440680b651235f925e3d0ebf0fd
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/8523
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
BUG: 1139998
Reviewed-on: http://review.gluster.org/8681
Reviewed-by: Kaleb KEITHLEY

cluster/dht: introduce locking api.

2014-10-20T14:55:11+00:00

Change-Id: I41389ba91951d3e63e617aa32cd0bee848261c72
BUG: 1139998
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/8521
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8679
Reviewed-by: Kaleb KEITHLEY

cluster/dht: Fix dht_access treating directory like files

2014-10-20T14:54:59+00:00

When the cluster topology changes due to add-brick, all sub
volumes of DHT will not contain the directories till a rebalance
is completed. Till the rebalance is run, if a caller bypasses
lookup and calls access due to saved/cached inode information
(like NFS server does) then, dht_access misreads the error
(ESTALE/ENOENT) from the new subvolumes and incorrectly tries
to handle the inode as a file. This results in the directories
in memory state in DHT to be corrupted and not heal even post
a rebalance.

This commit fixes the problem in dht_access thereby preventing
DHT from misrepresenting a directory as a file in the case
presented above.

Change-Id: Idcdaa3837db71c8fe0a40ec0084a6c3dbe27e772
BUG: 1139997
Signed-off-by: Shyam 
Reviewed-on: http://review.gluster.org/8462
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8678
Reviewed-by: Kaleb KEITHLEY