glusterfs.git/xlators/cluster/dht/src, branch v3.4.7

cluster/dht: Changed log level to DEBUG

2015-03-26T11:41:33+00:00

Changing log level from GF_LOG_INFO to GF_LOG_DEBUG
to prevent logs getting flooded.

This is the same fix as addressed by:
http://review.gluster.org/#/c/8621

Change-Id: I6fa04a848fe1aa5829c7c74d2ef9a5636d2dbda4
BUG: 1206120
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/10008
Reviewed-by: Humble Devassy Chirammal 
Reviewed-by: Kaleb KEITHLEY 
Tested-by: Gluster Build System

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/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