glusterfs.git, branch v3.10.8

doc: Added release-notes for 3.10.8

2017-11-30T14:46:41+00:00

Change-Id: I954c90442a017a0bec56bfa7a2a1adf7e8ec3ee2
BUG: 1508389
Signed-off-by: ShyamsundarR

features/locks: Fix memory leaks

2017-11-27T18:12:28+00:00

Backport of:
> BUG: 1515161

Change-Id: Ic1d2e17a7d14389b6734d1b88bd28c0a2907bbd6
BUG: 1517682
Signed-off-by: Xavier Hernandez

cluster/afr: Honor default timeout of 5min for analyzing split-brain files

2017-11-27T13:50:23+00:00

Problem:
After setting split-brain-choice option to analyze the file to resolve
the split brain using the command
"setfattr -n replica.split-brain-choice -v "choiceX" "
should allow to access the file from mount for default timeout of 5mins.
But the timeout was not honored and was able to access the file even after
the timeout.

Fix:
Call the inode_invalidate() in afr_set_split_brain_choice_cbk() so that
it will triger the cache invalidate after resetting the timer and the
split brain choice. So the next calls to access the file will fail with EIO.

Change-Id: I698cb833676b22ff3e4c6daf8b883a0958f51a64
BUG: 1514388
Signed-off-by: karthik-us 
(cherry picked from commit 933ec57ccda2c1ba5ce6f207313c3b6802e67ca3)

cluster/afr: Print heal info split-brain output in stream fashion

2017-11-17T11:30:39+00:00

Problem:
When we trigger the heal info split-brain command the o/p is not
streamed as it is received, but dumped at the end for all the bricks
together. This gives a perception that the command is hung.

Fix:
When we get a split brain entry while crawling throught the pending
heal entries, flush that immediately so that it prints the output
in a stream fashion and doesn't look like the cli is hung.

Change-Id: I7547e86b83202d66616749b8b31d4d0dff0abf07
BUG: 1514424
Signed-off-by: karthik-us 
(cherry picked from commit 05f9c13f4d69e4113f5a851f4097ef35ba3f33b2)

glusterd: use sys_lstat instead of lstat

2017-11-01T10:44:57+00:00

Showed up in 0symbol-check.t while testing something else.  Might as
well fix it now.

> Signed-off-by: Jeff Darcy 
> Reviewed-on: https://review.gluster.org/16820
> Reviewed-by: Prashanth Pai 

(cherry picked from commit 9ed98f23564387c5b436a0c6ec6d4393f970dcb9)
BUG: 1508036
Change-Id: Ic6b8214de6f486187afc4987c5ffbbca02c8997f

glusterd: delete source brick only once in reset-brick commit force

2017-10-31T18:08:14+00:00

While stopping the brick which is to be reset and replaced delete_brick
flag was passed as true which resulted glusterd to free up to source
brick before the actual operation. This results commit force to fail
failing to find the source brickinfo.

> mainline patch : https://review.gluster.org/#/c/18581/

Change-Id: I1aa7508eff7cc9c9b5d6f5163f3bb92736d6df44
BUG: 1507880
Signed-off-by: Atin Mukherjee 
(cherry picked from commit 0fb8acaa6ff80c43e46deac0ce66b29ae0df0ca4)

glusterd: clean up portmap on brick disconnect

2017-10-31T18:07:17+00:00

GlusterD's portmap entry for a brick is cleaned up when a PMAP_SIGNOUT event is
initiated by the brick process at the shutdown. But if the brick process crashes
or gets killed through SIGKILL then this event is not initiated and glusterd
ends up with a stale port. Since GlusterD's portmap traversal happens both ways,
forward for allocation and backward for registry search, there is a possibility
that glusterd might end up running with a stale port for a brick which
eventually will end up with clients to fail to connect to the bricks.

Solution is to clean up the port entry in case the process is down as
part of the brick disconnect event. Although with this the handling
PMAP_SIGNOUT event becomes redundant in most of the cases, but this is
the safeguard method to avoid glusterd getting into the stale port
issues.

This patch also needs to bring in the changes from change id
I705f101739ab1647ff52a92820d478354407264a which is needed for the
compilation to go through.

> mainline patch : https://review.gluster.org/#/c/18541/
>                  https://review.gluster.org/#/c/17129/

Change-Id: I04c5be6d11e772ee4de16caf56dbb37d5c944303
BUG: 1507749
Signed-off-by: Atin Mukherjee

glusterd: persist brickinfo's port change into glusterd's store

2017-10-31T05:19:02+00:00

Problem:
Consider a case where node reboot is performed and prior to reboot
brick was listening to 49153. Post reboot glusterd assigned 49152
to brick and started the brick process but the new port was never
persisted. Now when glusterd restarts glusterd always read the port
from its persisted store i.e 49153 however pmap signin happens with
the correct port i.e 49152.

Fix:
Make sure when glusterd_brick_start is called, glusterd_store_volinfo is
eventually invoked.

Change-Id: Ic0efbd48c51d39729ed951a42922d0e59f7115a1
BUG: 1507752
Signed-off-by: Gaurav Yadav

doc: Added release notes for 3.10.7 release

2017-10-30T16:53:52+00:00

Change-Id: I35669309585f9618a4aee332411e679eff8a33b1
BUG: 1499294
Signed-off-by: ShyamsundarR

md-cache: Use correct xattr keynames for virtual glusterfs ACLs.

2017-10-25T14:05:54+00:00

The "glusterfs.posix_acl." prefix does not catch the glusterfs posix acl
xattr keynames which are

	* "glusterfs.posix.acl" and
	* "glusterfs.posix.default_acl"

Using the GF_POSIX_ACL_ACCESS and GF_POSIX_ACL_DEFAULT defines directly
is the savest option.

Guenther

> Change-Id: I5aba64b26b6cbec850ea02316dd9f069400e857f
> BUG: 1476295
> Signed-off-by: Guenther Deschner 
> Reviewed-on: https://review.gluster.org/17909
> Reviewed-by: Michael Adam 
> Smoke: Gluster Build System 
> Reviewed-by: Niels de Vos 
> Tested-by: Niels de Vos 
> CentOS-regression: Gluster Build System 
> (cherry picked from commit 5fe8555800cbc9818e7c976f63499795a378cd8d)
> Signed-off-by: Günther Deschner 

Change-Id: I5aba64b26b6cbec850ea02316dd9f069400e857f
BUG: 1499890
Signed-off-by: Günther Deschner