glusterfs.git, branch v3.4.6beta2

doc: release notes for 3.4.6 GA

2014-10-30T17:16:13+00:00

Change-Id: I4981af8e82606ac0dea1560b3d0497d5a2a48ec1
BUG: 1125245
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/9015
Tested-by: Gluster Build System

logrotate: gluster logrotate config should not be global

2014-10-30T15:31:38+00:00

Issue : Previously glusterfs logrotate config file pollutes
global config. So moved the directives inside the curly braces,
so they don't pollute the global config state.

Backport of fix from BZ 1126801, http://review.gluster.org/#/c/9001/

Change-Id: Iafaa6bb295b7dd7554c2654716cc9aeafd6d7a68
BUG: 1158923
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/9013
Reviewed-by: Humble Devassy Chirammal 
Tested-by: Gluster Build System 
Reviewed-by: Lalatendu Mohanty 
Reviewed-by: Justin Clift

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

socket: disallow CBC cipher modes

2014-10-29T17:31:40+00:00

This is related to CVE-2014-3566 a.k.a. POODLE.

	http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566

POODLE is specific to CBC cipher modes in SSLv3.  Because there is no
way to prevent SSLv3 fallback on a system with an unpatched version of
OpenSSL, users of such systems can only be protected by disallowing CBC
modes.  The default cipher-mode specification in our code has been
changed accordingly.

cherry picked from http://review.gluster.org/#/c/8962/
BZ 1155328

Change-Id: Id38a7eb3ab55058a0ee5dda9cb4c62b49b1ab9cb
BUG: 1155630
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/8967
Reviewed-by: Jeff Darcy

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

libglusterfs/syncop: implement inodelk

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

Change-Id: Iea489157490b70cb2bb03576b0d4943c6d8f052d
BUG: 1139998
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/8522
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8680
Reviewed-by: N Balachandran 
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