glusterfs.git, branch v3.6.0

doc: Release Notes for GlusterFS 3.6.0

2014-10-31T13:09:55+00:00

Signed-off-by: Niels de Vos  
Signed-off-by: Venky Shankar 
Signed-off-by: Vijay Bellur  
Signed-off by: Emmanuel Dreyfus 
Signed-off by: Kaushal Madappa 
Signed-off by: Krishnan Parthasarathi 
Signed-off by: Xavier Hernandez 
Signed-off by: Harshavardhana 
Signed-off-by: Ravishankar N 

Change-Id: I9973f70eedabf408c452d4018d7521e8b59fb4a7
Reviewed-on: http://review.gluster.org/8993
Reviewed-by: Vijay Bellur 
Tested-by: Vijay Bellur

cluster/afr: Perform post-op in entry selfheal inside locks

2014-10-31T13:09:28+00:00

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

Take entrylks in xlator domain before doing post-op (undo-pending) in
entry self-heal. This is to prevent a parallel name self-heal on
an entry under @fd->inode from reading pending xattrs while it is
being modified by SHD after entry sh below, given that
name self-heal takes locks ONLY in xlator domain and is free to read
pending changelog in the absence of the following locking.

Change-Id: I0bc92978efc0741d6e3f2439540d008e31472313
BUG: 1136821
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/9030
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Pranith Kumar Karampuri 
Reviewed-by: Vijay Bellur 
Tested-by: Vijay Bellur

features/snapview-server: verify the fs instance in revalidated lookups as well

2014-10-30T18:39:59+00:00

Change-Id: I691635e60aba72642c3c79d7da472884f1228301
BUG: 1158791
Reviewed-on: http://review.gluster.org/9008
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

features/snapview-server: check if the reference to the snapshot world is correct before doing any fop

2014-10-30T18:39:15+00:00

The following operations might lead to problems:
* Create a file on the glusterfs mount point
* Create a snapshot (say "snap1")
* Access the contents of the snapshot
* Delete the file from the mount point
* Delete the snapshot "snap1"
* Create a new snapshot "snap1"

Now accessing the new snapshot "snap1" gives problems. Because the inode and
dentry created for snap1 would not be deleted upon the deletion of the snapshot
(as deletion of snapshot is a gluster cli operation, not a fop). So next time
upon creation of a new snap with same name, the previous inode and dentry itself
will be used. But the inode context contains old information about the glfs_t
instance and the handle in the gfapi world. Directly accessing them without
proper check leads to ENOTCONN errors. Thus the glfs_t instance should be
checked before accessing. If its wrong, then right instance should be obtained
by doing the lookup.

Change-Id: I975245b8f6b7fea0a90eb5e36e8149d12457ac10
BUG: 1158791
Reviewed-on: http://review.gluster.org/9007
Reviewed-by: Vijay Bellur 
Tested-by: Vijay Bellur

logrotate: gluster logrotate config should not be global

2014-10-30T08:54:07+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.

Change-Id: I8836893dfcdf457d9c5d766612d687bfce64e2ae
BUG: 1158456
"Signed-off-by: Lalatendu Mohanty "
"Reviewed-on: http://review.gluster.org/8994"
"Reviewed-by: Niels de Vos "
"Tested-by: Gluster Build System "
(cherry picked from commit a5d73daabf6df95bc73b186d92f3e2d1239a6f8a)
Signed-off-by: Lalatendu Mohanty 
Reviewed-on: http://review.gluster.org/9000
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

socket: disallow CBC cipher modes

2014-10-29T11:37:55+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.  Users can still set their own cipher modes if they
wish.  To support them, the ssl-authz.t test script provides an example
of how to combine the CBC exclusion with other criteria in a script.

Change-Id: Ib1fa547082fbb7de9df94ffd182b1800d6e354e5
BUG: 1157659
Signed-off-by: Jeff Darcy 
Reviewed-on: http://review.gluster.org/8962
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8987
Reviewed-by: Niels de Vos 
Tested-by: Niels de Vos

Avoid spurious EINVAL in posix_readdir()

2014-10-29T09:26:56+00:00

On non Linux systems, we check that seekdir() succeeds and we return
EINVAL if it does not. We need this to avoid infinite loops if some
other component in GlusterFS makes an invalid seekdir() usage. This
was introduced in this change: http://review.gluster.org/#/c/8760/

But seekdir() also fails when using the offset returned for the
last entry, and this is expected behavior. As a result, the seekdir()
test produces a spurious EINVAL when reaching end of directory. That
error is not propagated to calling process, but it may harm internal
GlusterFS processing. At least it produce a spurious error message
in brick's log.

We fix the problem by remembering the last entry offset in fd private
data. When a new posix_readdir() invocation requests that offset,
we avoid returning EINVAL.

Backport of I4e67a2ea46538aae63eea663dd4aa33b16ad24c7

BUG: 1138897
Change-Id: I4e98294d157f67ae1a1f0ece1562c77d1219da40
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/8933
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

Hooks : Infinite while loop introduced by another change.

2014-10-28T10:21:28+00:00

A change made to all the hook scripts introduced an
infinite while loop in the script S31ganesha-reset.sh.
It resulted in 100% CPU usage by this script.

Change-Id: I8133c92d46616b6534fc88158d6dbfca49875f4a
BUG: 1157374
Reviewed-on: http://review.gluster.org/8974
Reviewed-by: Raghavendra Talur 
Reviewed-by: soumya k 
Reviewed-by: Vijay Bellur 
Tested-by: Vijay Bellur

ec: Correctly handle xtime extended attribute

2014-10-28T08:40:02+00:00

Change-Id: I2bd34f063d6bf1835d5ae57a8e9aa03f3ec3deb3
BUG: 1156405
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/8976
Tested-by: Gluster Build System 
Reviewed-by: Dan Lambright

ec: Fix rebalance issues

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

Some issues in ec xlator made that rebalance didn't complete
successfully and generated some warnings and errors in the
log. The most critical error was a race condition that caused
false corruption detection when two specific operations were
executed sequentially and they shared the same lock.

This explains the problem:

1. A setxattr is issued.
2. setxattr: ec locks the inode before updating the xattr.
3. setxattr: The xattr is updated.
4. setxattr: Upper xlator is notified that the operation completed.
5. setxattr: A background task is initiated to update the version
             of the file.
6. A stat is issued on the same file.
7. stat: Since the lock is already acquired, it's reused.
8. stat: A lookup is issued to determine version and size
         information of the file.

At this point, operations 5 and 8 can interfere. This can make that
lookup sees different information on each brick, determining that
some bricks are corrupted and incorrectly excluding them from the
operation and initiating a self-heal. In some cases this false
detection combined with self-heal could lead to invalid updates of
the trusted.ec.size xattr, leaving the file smaller than it should
be.

This only happens if the first operation does not perform a lookup,
because chained operations reuse the information returned by the
previous one, avoiding this kind of problems.

To solve this, now the background update is executed atomically with
the posterior unlock. This avoids some reuses of the lock while
updating. However this reduces performance because the window in
which new requests can reuse the lock is much smaller now. This has
been alleviated by using the same technique implemented in AFR (i.e.
waiting some time before releasing the lock).

Some minor changes also introduced in this patch:

* Bug in management of 'trusted.glusterfs.pathinfo' that was writing
  beyond the allocated space.
* Uninitialized variable.
* trusted.ec.config was not created for regular files created with
  mknod.
* An invalid state was used in access fop.

This is a backport of http://review.gluster.org/8947/

Change-Id: Idfaf69578ed04dbac97a62710326729715b9b395
BUG: 1152903
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/8948
Tested-by: Gluster Build System 
Reviewed-by: Dan Lambright