glusterfs.git, branch v4.1.2

doc: Added release notes for 4.1.2

2018-07-24T12:39:20+00:00

Fixes: bz#1594908
Change-Id: I93db801c1292b8f57e35157ce2b503fefa6cb2f2
Signed-off-by: ShyamsundarR

glusterd: _is_prefix should handle 0-length paths

2018-07-24T10:28:55+00:00

If one of the paths given to _is_prefix is 0-length, then it is not a
prefix of the other. Hence, _is_prefix should return false.

Change-Id: I54aa577a64a58940ec91872d0d74dc19cff9106d
fixes: bz#1599785
Signed-off-by: Kaushal M

doc: Correct release notes to remove py3 support

2018-07-24T10:28:50+00:00

Updates: bz#1594908

Change-Id: I6cefb3b6abc1b38981da4959f1be24814be6888c
Signed-off-by: ShyamsundarR

geo-rep/scheduler: Fix EBUSY trace back

2018-07-23T23:42:54+00:00

Fix the trace back during temporary mount
cleanup. Temporary mount is done to touch
the root required for checkpoint to complete.

Backport of:
 > Patch: https://review.gluster.org/#/c/20476/
 > BUG: 1598977
 > Change-Id: I97fea538e92c4ef0747747e981ef98499504e336
 > Signed-off-by: Kotresh HR 
(cherry picked from commit 271510b09d0613887f983b1e3dad5c55cdc6cd07)


fixes: bz#1600941
Change-Id: I97fea538e92c4ef0747747e981ef98499504e336
Signed-off-by: Kotresh HR

afr: switch lk_owner only when pre-op succeeds

2018-07-23T23:42:15+00:00

Problem:
In a disk full scenario, we take a failure path in afr_transaction_perform_fop()
and go to unlock phase. But we change the lk-owner before that, causing unlock
to fail. When mount issues another fop that takes locks on that file, it hangs.

Fix:
Change lk-owner only when we are about to perform the fop phase.
Also fix the same issue for arbiters when afr_txn_arbitrate_fop() fails the fop.

Also removed the DISK_SPACE_CHECK_AND_GOTO in posix_xattrop. Otherwise truncate
to zero will fail pre-op phase with ENOSPC when the user is actually trying to
freee up space.

Change-Id: Ic4c8a596b4cdf4a7fc189bf00b561113cf114353
fixes: bz#1603056
Signed-off-by: Ravishankar N 
(cherry picked from commit ec0d7d77de3e4bd485a4fa2e53c9137e25c71ce7)

posix: check before removing stale symlink

2018-07-23T23:41:37+00:00

BZ 1564071 complains of directories with missing gfid symlinks and
corresponding "Found stale gfid handle" messages in the logs. Hence
add a check to see if the symlink points to an actual directory before
removing it.

Note: Removing stale symlinks was added via commit
3e9a9c029fac359477fb26d9cc7803749ba038b2

Change-Id: I5d91fab8e5f3a621a9ecad4a1f9c898a3c2d346a
Updates: bz#1603099
Signed-off-by: Ravishankar N 
(cherry picked from commit 9ab218be5e69b9f71fe4eea9ca8d114b78cafd25)

cluster/afr: Prevent execution of code after call_count decrementing

2018-07-10T08:49:30+00:00

Problem:
When call_count is decremented by one thread, another thread can
go ahead with the operation leading to undefined behavior for the
thread executing statements after decrementing call count.

Fix:
Do the operations necessary before decrementing call count.

fixes bz#1599629
Change-Id: Icc90cd92ac16e5fbdfe534d9f0a61312943393fe
Signed-off-by: Pranith Kumar K 
(cherry picked from commit 03f1f5bdc46076178f1afdf8e2a76c5b973fe11f)

afr: heal gfids when file is not present on all bricks

2018-07-09T15:18:31+00:00

commit 20fa80057eb430fd72b4fa31b9b65598b8ec1265 introduced a regression
wherein if a file is present in only 1 brick of replica *and* doesn't
have a gfid associated with it, it doesn't get healed upon the next
lookup from the client. Fix it.

Change-Id: I7d1111dcb45b1b8b8340a7d02558f05df70aa599
fixes: bz#1597117
Signed-off-by: Ravishankar N 
(cherry picked from commit eb472d82a083883335bc494b87ea175ac43471ff)

cluster/afr: Make sure lk-owner is assigned at the time of lock

2018-07-04T15:04:30+00:00

Problem:
In the new eager-lock implementation lk-owner is assigned after the
'local' is added to the eager-lock list, so there exists a possibility
of lock being sent even before lk-owner is assigned.

Fix:
Make sure to assign lk-owner before adding local to eager-lock list

fixes bz#1598193
Change-Id: I26d1b7bcf3e8b22531f1dc0b952cae2d92889ef2
Signed-off-by: Pranith Kumar K 
(cherry picked from commit c6f93e422855f656d3a86461a8458f37ad0103eb)

posix/ctime: Fix differential ctime duing entry operations

2018-07-02T17:27:52+00:00

We should not be relying on backend file's time attributes
to load the initial ctime time attribute structure. This
is incorrect as each replica set would have witnessed the
file creation at different times.

For new file creation, ctime, atime and mtime should be
same, hence initiate the ctime structure with the time
from the frame. But for the files which were created
before ctime feature is enabled, this is not accurate
but still fine as the times would get eventually accurate.

Backport of:
  > Patch: https://review.gluster.org/#/c/20281/
  > BUG: 1592275
  > Change-Id: I206a469c83ee7b26da2fe096ae7bf8ff5986ad67
  > Signed-off-by: Kotresh HR 
  (cherry picked from commit 841991130c94e3fcf4076917be6da9ce90406932)

fixes: bz#1593537
Change-Id: I206a469c83ee7b26da2fe096ae7bf8ff5986ad67
Signed-off-by: Kotresh HR