glusterfs.git/xlators, branch v3.12.3

glusterd: restart the brick if qorum status is NOT_APPLICABLE_QUORUM

2017-11-10T08:52:14+00:00

If a volume is not having server quorum enabled and in a trusted storage
pool all the glusterd instances from other peers are down, on restarting
glusterd the brick start trigger doesn't happen resulting into the
brick not coming up.

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

Change-Id: If1458e03b50a113f1653db553bb2350d11577539
BUG: 1511301
Signed-off-by: Atin Mukherjee 
(cherry picked from commit 635c1c3691a102aa658cf1219fa41ca30dd134ba)

md-cache: avoid checking the xattr value buffer with string functions.

2017-11-09T09:07:06+00:00

xattrs may very well contain binary, non-text data with leading 0
values. Using strcmp for checking empty values is not the appropriate
thing to do: In the best case, it might treat a binary xattr value
starting with 0 from being cached (and hence also from being reported
back with xattr). In the worst case, we might read beyond the end
of a data blob that does contain any zero byte.

We fix this by checking the length of the data blob and checking
the first byte against 0 if the length is one.

> Signed-off-by: Guenther Deschner 
> Pair-Programmed-With: Michael Adam 
> Change-Id: If723c465a630b8a37b6be58782a2724df7ac6b11
> BUG: 1476324
> Reviewed-on: https://review.gluster.org/17910
> Reviewed-by: Michael Adam 
> Smoke: Gluster Build System 
> Reviewed-by: Poornima G 
> Tested-by: Poornima G 
> CentOS-regression: Gluster Build System 
> (cherry picked from commit ab4ffdac9dec1867f2d9b33242179cf2b347319d)

Change-Id: If723c465a630b8a37b6be58782a2724df7ac6b11
BUG: 1499892
Signed-off-by: Günther Deschner

glusterd : introduce timer in mgmt_v3_lock

2017-11-06T12:16:15+00:00

Problem:
In a multinode environment, if two of the op-sm transactions
are initiated on one of the receiver nodes at the same time,
there might be a possibility that glusterd  may end up in
stale lock.

Solution:
During mgmt_v3_lock a registration is made to  gf_timer_call_after
which release the lock after certain period of time

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

Change-Id: I16cc2e5186a2e8a5e35eca2468b031811e093843
BUG: 1503239
Signed-off-by: Gaurav Yadav

protocol/server: fix the comparision logic in case of subdir mount

2017-11-06T11:43:42+00:00

without the fix, the stat entry on a file would return inode==1 for
many files, in case of subdir mount

This happened with the confusion of return value of 'gf_uuid_compare()',
it is more like strcmp, instead of a gf_boolean return value, and hence 
resulted in the bug.

Change-Id: I31b8cbd95eaa3af5ff916a969458e8e4020c86bb
BUG: 1505527
Signed-off-by: Amar Tumballi 
(cherry picked from commit 2ade36cd98ea0f5bd2a8f619a19c20438318afaf)

protocol/client: handle the subdir handshake properly for add-brick

2017-11-06T11:43:04+00:00

There should be different way we handle handshake in case of subdir
mount for the first time, and in case of subsequent graph changes.

Change-Id: I2a7ba836433bb0a0f4a861809e2bb0d7fbc4da54
BUG: 1505323
Signed-off-by: Amar Tumballi 
(cherry picked from commit 9aa574a51b84717c1f3949ed2e28a49e49840a93)

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

2017-11-06T06:15:30+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

> 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: 1499889
Signed-off-by: Günther Deschner

glusterd: clean up portmap on brick disconnect

2017-11-06T06:09:45+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.

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

Change-Id: I04c5be6d11e772ee4de16caf56dbb37d5c944303
BUG: 1507747
Signed-off-by: Atin Mukherjee 
(cherry picked from commit 30e0b86aae00430823f2523c6efa3c4ebbf0a478)

glusterd: fix brick restart parallelism

2017-11-06T06:09:21+00:00

glusterd's brick restart logic is not always sequential as there is
atleast three different ways how the bricks are restarted.
1. through friend-sm and glusterd_spawn_daemons ()
2. through friend-sm and handling volume quorum action
3. through friend handshaking when there is a mimatch on quorum on
friend import.

In a brick multiplexing setup, glusterd ended up trying to spawn the
same brick process couple of times as almost in fraction of milliseconds
two threads hit glusterd_brick_start () because of which glusterd didn't
have any choice of rejecting any one of them as for both the case brick
start criteria met.

As a solution, it'd be better to control this madness by two different
flags, one is a boolean called start_triggered which indicates a brick
start has been triggered and it continues to be true till a brick dies
or killed, the second is a mutex lock to ensure for a particular brick
we don't end up getting into glusterd_brick_start () more than once at
same point of time.

Change-Id: I292f1e58d6971e111725e1baea1fe98b890b43e2
BUG: 1508283
Signed-off-by: Atin Mukherjee 
(cherry picked from commit 82be66ef8e9e3127d41a4c843daf74c1d8aec4aa)

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

2017-11-02T09:53:37+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: 1507877
Signed-off-by: Atin Mukherjee 
(cherry picked from commit 0fb8acaa6ff80c43e46deac0ce66b29ae0df0ca4)

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

2017-11-02T09:52:58+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: 1507748
Signed-off-by: Gaurav Yadav