glusterfs.git, branch v4.1.3

doc: Release notes for v4.1.3

2018-08-27T13:03:24+00:00

Change-Id: Ia944a2353f0a89b61f66bde7f270489dff3793b4
fixes: bz#1607945
Signed-off-by: ShyamsundarR

gfapi : Handle the path == "" glfs_resolve_at

2018-08-22T01:05:53+00:00

Currently there is no check for path = "" in glfs_resolve_at.
So if application sends an empty path, then the function resolves
into the parent inode which is incorrect. Plus modified possible
of "path" with "origpath" in the same function.

Change-Id: Ie5ff9ce4b771607b7dbb3fe00704fe670421792a
fixes: bz#1618347
Signed-off-by: Jiffin Tony Thottan 
(cherry picked from commit febee007bb1a99d65300630c2a98cbb642b1c8dc)

Bash integration script should namespace variables

2018-08-21T14:13:40+00:00

In the original submitted script, it looks like there was effort
put into namespacing all global variables. However a few mistakes
remained.

GLUSTER_TOP_SUBOPTIONSx were defined, but TOP_SUBOPTIONSx were
referenced. This was likely an unrecognized defect in the
original code submission? These are now corrected to refer to
GLUSTER_TOP_SUBOPTIONSx.

FINAL_LIST, LIST, and TOP were leaked into all Bash shells and
used by the command completion functions. The most problematic
of these was TOP, which was declared with "-i" making it an
integer. This cause other code which used TOP to define a path
to fail like this:

    $ bash
    $ TOP=/abc
    bash: /abc: syntax error: operand expected (error token is "/abc")

These are now qualified as GLUSTER_FINAL_LIST, GLUSTER_LIST, and
GLUSTER_TOP to reduce impact on scripts that might choose to use
these extremely common variable names.

> Change-Id: Ic96eda8efd1f3238bbade6c6ddb69118e8d82158
> Signed-off-by: Mark Mielke 

(cherry picked from commit 89545e745e4075845c18078be67a31dea93a4e88)

Change-Id: Ic96eda8efd1f3238bbade6c6ddb69118e8d82158
Fixes: bz#1425326
Signed-off-by: Mark Mielke

dht: Delete MDS internal xattr from dict in dht_getxattr_cbk

2018-08-16T14:31:37+00:00

Problem: At the time of fetching xattr to heal xattr by afr
         it is not able to fetch xattr because posix_getxattr
         has a check to ignore if xattr name is MDS

Solution: To ignore same xattr update a check in dht_getxattr_cbk
          instead of having a check in posix_getxattr

Backport of:
 > BUG: 1584098
 > Change-Id: I86cd2b2ee08488cb6c12f407694219d57c5361dc
 > Signed-off-by: Mohit Agrawal 

Change-Id: I86cd2b2ee08488cb6c12f407694219d57c5361dc
fixes: bz#1611116
Signed-off-by: Mohit Agrawal

geo-rep : fix possible crash

2018-08-16T14:31:14+00:00

Problem : In 'glusterd_verify_slave' while tokenizing error message
          we call 'strtok_r' and store return value in 'tmp' which
          can be NULL. We are passing this 'tmp' as 1st argument to
          'strcmp' which will lead to segmentation fault.
Solution : before calling 'strcmp' we should NULL check 'tmp'.

Backport of:
 > Change-Id: Ifd3864b904afe6cd09d9e5a4b55c6d0578e22b9d
 > BUG: 1602121
 > Signed-off-by: Sunny Kumar 

Change-Id: Ifd3864b904afe6cd09d9e5a4b55c6d0578e22b9d
fixes: bz#1611115
Signed-off-by: Sunny Kumar

geo-rep: Fix issues with gfid conflict handling

2018-08-16T04:21:14+00:00

1. MKDIR/RMDIR is recorded on all bricks. So if
   one brick succeeds creating it, other bricks
   should ignore it. But this was not happening.
   The fix rename of directories in hybrid crawl,
   was trying to rename the directory to itself
   and in the process crashing with ENOENT if the
   directory is removed.

2. If file is created, deleted and a directory is
   created with same name, it was failing to sync.
   Again the issue is around the fix for rename
   of directories in hybrid crawl. Fixed the same.

   If the same case was done with hardlink present
   for the file, it was failing. This patch fixes
   that too.

Backport of:
 > BUG: 1598884
 > Change-Id: I6f3bca44e194e415a3d4de3b9d03cc8976439284
 > Signed-off-by: Kotresh HR 

fixes: bz#1611114
Change-Id: I6f3bca44e194e415a3d4de3b9d03cc8976439284
Signed-off-by: Kotresh HR

geo-rep: Fix symlink rename syncing issue

2018-08-16T04:21:01+00:00

Problem:
   Geo-rep sometimes fails to sync the rename of symlink
if the I/O is as follows

  1. touch file1
  2. ln -s "./file1" sym_400
  3. mv sym_400 renamed_sym_400
  4. mkdir sym_400

 The file 'renamed_sym_400' failed to sync to slave

Cause:
  Assume there are three distribute subvolume (brick1, brick2, brick3).
  The changelogs are recorded as follows for above I/O pattern.
  Note that the MKDIR is recorded on all bricks.

  1. brick1:
     -------

     CREATE file1
     SYMLINK sym_400
     RENAME sym_400 renamed_sym_400
     MKDIR sym_400

  2. brick2:
     -------

     MKDIR sym_400

  3. brick3:
     -------

     MKDIR sym_400

  The operations on 'brick1' should be processed sequentially. But
  since MKDIR is recorded on all the bricks, The brick 'brick2/brick3'
  processed MKDIR first before 'brick1' causing out of order syncing
  and created directory sym_400 first.

  Now 'brick1' processed it's changelog.

     CREATE file1 -> succeeds
     SYMLINK sym_400 -> No longer present in master. Ignored
     RENAME sym_400 renamed_sym_400
            While processing RENAME, if source('sym_400') doesn't
            present, destination('renamed_sym_400') is created. But
            geo-rep stats the name 'sym_400' to confirm source file's
            presence. In this race, since source name 'sym_400' is
            present as directory, it doesn't create destination.
            Hence RENAME is ignored.

Fix:
  The fix is not rely only on stat of source name during RENAME.
  It should stat the name and if the name is present, gfid should
  be same. Only then it can conclude the presence of source.

Backport of:
 > BUG: 1600405
 > Change-Id: I9fbec4f13ca6a182798a7f81b356fe2003aff969
 > Signed-off-by: Kotresh HR 

fixes: bz#1611113
Change-Id: I9fbec4f13ca6a182798a7f81b356fe2003aff969
Signed-off-by: Kotresh HR

geo-rep: Fix geo-rep for older versions of unshare

2018-08-16T04:20:47+00:00

Geo-rep mounts are private to worker. It uses
mount namespace using unshare command to achieve
the same. Well, the unshare command has to support
'--propagation' option. So geo-rep breaks on the
systems with older unshare version. The patch
makes it fall back to lazy umount behaviour if
the unshare does not support propagation option.

Backport of:
 > BUG: 1589782
 > Change-Id: Ia614f068aede288d63ac62fea4461b1865066054
 > Signed-off-by: Kotresh HR 

fixes: bz#1611111
Change-Id: Ia614f068aede288d63ac62fea4461b1865066054
Signed-off-by: Kotresh HR

glusterd: memory leak in geo-rep status

2018-08-16T04:20:32+00:00

Backport of:
 > BUG: 1580352
 > Change-Id: I9648e73090f5a2edbac663a6fb49acdb702cdc49
 > Signed-off-by: Sanju Rakonde 

fixes: bz#1611110
Change-Id: I9648e73090f5a2edbac663a6fb49acdb702cdc49
Signed-off-by: Sanju Rakonde

geo-rep/scheduler: Fix crash

2018-08-16T04:20:20+00:00

Fix crash where session_name is referenced
before assignment. Well, this is a corner
case where the geo-rep session exists and
the status output doesn't show any rows.
This might happen when glusterd is down
or when the system is in inconsistent state
w.r.t glusterd.

Backpor of:
 > BUG: 1576179
 > Change-Id: Iec1557e01b35068041b4b3c1aacee2bfa0e05873
 > Signed-off-by: Kotresh HR 

fixes: bz#1611108
Change-Id: Iec1557e01b35068041b4b3c1aacee2bfa0e05873
Signed-off-by: Kotresh HR