glusterfs.git/xlators, branch v3.4.6beta2

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

cluster/dht: Prevent dht_access from going into a loop.

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

If access fails with ENOTCONN, do not wind to same subvol.
We wind to first-up-subvol if access fails with ENOTCONN.
In few cases, if dht has only 1 subvolume, and access fails with
ENOTCONN, we go into a infinite loop of winding to same subvol

The fix is to check if we previously wound to same subvol, and
fail if first-up-subvol is same.

Change-Id: Ib5d3ce7d33e8ea09147905a7df1ed280874fa549
BUG: 1139996
Signed-off-by: shishir gowda 
Reviewed-on: http://review.gluster.org/5319
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati 
Reviewed-on: http://review.gluster.org/8677
Reviewed-by: N Balachandran 
Reviewed-by: Kaleb KEITHLEY

dht: fix rename race

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

Additional check to check if we created the linkto
file before deleting it in the rename cleanup function

Change-Id: I919cd7cb24f948ba4917eb9cf50d5169bb730a67
BUG: 1139988
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8338
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8676
Reviewed-by: Kaleb KEITHLEY

storage/posix: removing deleting entries in case of creation failures

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

The code is not atomic enough to not to delete a dentry created by a
prallel dentry creation operation.

Change-Id: I9bd6d2aa9e7a1c0688c0a937b02a4b4f56d7aa3d
BUG: 1139988
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/8327
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8675
Reviewed-by: Kaleb KEITHLEY