glusterfs.git/xlators, branch v6.5

features/utime: always update ctime at setattr

2019-08-07T05:09:15+00:00

For the nfs EXCLUSIVE mode create may sets a later time
to mtime (at verifier), it should not set to ctime for
storage.ctime does not allowed set ctime to a earlier time.

 /* Earlier, mdata was updated only if the existing time is less
  * than the time to be updated. This would fail the scenarios
  * where mtime can be set to any time using the syscall. Hence
  * just updating without comparison. But the ctime is not
  * allowed to changed to older date.
  */

According to kernel's setattr, always set ctime at setattr,
and doesnot set ctime from mtime at storage.ctime.

Backport of:
 > Patch: https://review.gluster.org/23154
 > Change-Id: I5cfde6cb7f8939da9617506e3dc80bd840e0d749
 > BUG: 1737288
 > Signed-off-by: Kinglong Mee 

Change-Id: I5cfde6cb7f8939da9617506e3dc80bd840e0d749
fixes: bz#1737746
Signed-off-by: Kotresh HR

posix/ctime: Fix race during lookup ctime xattr heal

2019-08-07T05:07:56+00:00

Problem:
Ctime heals the ctime xattr ("trusted.glusterfs.mdata") in lookup
if it's not present. In a multi client scenario, there is a race
which results in updating the ctime xattr to older value.

e.g. Let c1 and c2 be two clients and file1 be the file which
doesn't have the ctime xattr. Let the ctime of file1 be t1.
(from backend, ctime heals time attributes from backend when not present).

Now following operations are done on mount
c1 -> ls -l /mnt/file1  |   c2 -> ls -l /mnt/file1;echo "append" >> /mnt/file1;

The race is that the both c1 and c2 didn't fetch the ctime xattr in lookup,
so both of them tries to heal ctime to time 't1'. If c2 wins the race and
appends the file before c1 heals it, it sets the time to 't1' and updates
it to 't2' (because of append). Now c1 proceeds to heal and sets it to 't1'
which is incorrect.

Solution:
Compare the times during heal and only update the larger time. This is the
general approach used in ctime feature but got missed with healing legacy
files.

Backport of:
 > Patch: https://review.gluster.org/23131
 > BUG: 1734299
 > Change-Id: I930bda192c64c3d49d0aed431ce23d3bc57e51b7
 > Signed-off-by: Kotresh HR 

fixes: bz#1737745
Change-Id: I930bda192c64c3d49d0aed431ce23d3bc57e51b7
Signed-off-by: Kotresh HR

features/utime: Fix mem_put crash

2019-08-06T07:23:43+00:00

Problem:
When frame->local is not null FRAME_DESTROY calls mem_put on it.
Since the stub is already destroyed in call_resume(), it leads
to crash

Fix:
Set frame->local to NULL before calling call_resume()

Backport of:
 > Patch: https://review.gluster.org/23091
 > BUG: 1593542
 > Change-Id: I0f8adf406f4cefdb89d7624ba7a9d9c2eedfb1de
 > Signed-off-by: Pranith Kumar K 

fixes: bz#1733885
Change-Id: I0f8adf406f4cefdb89d7624ba7a9d9c2eedfb1de
Signed-off-by: Kotresh HR

ctime: Set mdata xattr on legacy files

2019-08-06T07:23:43+00:00

Problem:
The files which were created before ctime enabled would not
have "trusted.glusterfs.mdata"(stores time attributes) xattr.
Upon fops which modifies either ctime or mtime, the xattr
gets created with latest ctime, mtime and atime, which is
incorrect. It should update only the corresponding time
attribute and rest from backend

Solution:
Creating xattr with values from brick is not possible as
each brick of replica set would have different times.
So create the xattr upon successful lookup if the xattr
is not created

Note To Reviewers:
The time attributes used to set xattr is got from successful
lookup. Instead of sending the whole iatt over the wire via
setxattr, a structure called mdata_iatt is sent. The mdata_iatt
contains only time attributes.

Backport of:
 > Patch:  https://review.gluster.org/22936
 > Change-Id: I5e535631ddef04195361ae0364336410a2895dd4
 > BUG: 1593542
 > Signed-off-by: Kotresh HR 

Change-Id: I5e535631ddef04195361ae0364336410a2895dd4
updates: bz#1733885
Signed-off-by: Kotresh HR

features/snapview-server: obtain the list of snapshots inside the lock

2019-08-01T10:45:16+00:00

The current list of snapshots from priv->dirents is obtained outside
the lock.

Change-Id: I8876ec0a38308da5db058397382fbc82cc7ac177
Fixes: bz#1731509
(cherry picked from commit 8e795617fd6f5193d0d52a336059ce1a28108c0e)

cluster/dht: Fix directory perms during selfheal

2019-07-29T06:41:59+00:00

Fixed a bug in the revalidate code path that wiped out
directory permissions if no mds subvol was found.

Backport of: 
> Change-Id: I8b4239ffee7001493c59d4032a2d3062586ea115
> fixes: bz#1716830
> Signed-off-by: N Balachandran 

Change-Id: I8b4239ffee7001493c59d4032a2d3062586ea115
fixes: bz#1716848
Signed-off-by: N Balachandran

glusterd: do not mark skip_locking as true for geo-rep operations

2019-07-24T14:15:03+00:00

We need to send the commit req to peers in case of geo-rep
operations even though it is a no volname operation. In commit
phase peers try to set the txn_opinfo which will fail because
it is a no volname operation where we don't require a commit
phase. We mark skip_locking as true for no volname operations,
but we have to give an exception to geo-rep operations, so that
they can set txn_opinfo in commit phase.

Please refer to detailed RCA at the bug: 1730545

fixes: bz#1730545

Cherrypicked from https://review.gluster.org/#/c/glusterfs/+/23034/

> Change-Id: I9f2478b12a281f6e052035c0563c40543493a3fc
> Signed-off-by: Sanju Rakonde 

Change-Id: I9f2478b12a281f6e052035c0563c40543493a3fc
Signed-off-by: Sanju Rakonde

features/snapview-server: use the same volfile server for gfapi options

2019-07-16T05:00:24+00:00

snapview server xlator makes use of "localhost" as the volfile server while
initing the new glfs instance to talk to a snapshot. While localhost is fine,
better use the same volfile server that was used to start the snapshot
daemon containing the snapview-server xlator.

Change-Id: I4485d39b0e3d066f481adc6958ace53ea33237f7
fixes: bz#1727984
Signed-off-by: Raghavendra Bhat 
(cherry picked from commit 36f6e6df0ff15d0464b869803710adca2b65e8ba)

glusterd: add GF_TRANSPORT_BOTH_TCP_RDMA in glusterd_get_gfproxy_client_volfile

2019-07-16T04:56:14+00:00

... with out which volume creation fails with "volume create: : failed:
Failed to create volume files"

>Fixes: bz#1716812
>Change-Id: I2f4c2c6d5290f066b54e1c1db19e25db9937bedb
>Signed-off-by: Atin Mukherjee 

Fixes: bz#1721105
Change-Id: I2f4c2c6d5290f066b54e1c1db19e25db9937bedb
Signed-off-by: Atin Mukherjee

mgmt/glusterd: Fix a memory leak when peer detach fails

2019-07-16T04:55:17+00:00

Dictionary object is not being unref'd when an error happens
in __glusterd_handle_cli_deprobe(). This patch addresses that problem.

Change-Id: I11e1f92d06dc9edd1260845256f435ea31ef1a87
fixes: bz#1683815
Signed-off-by: Vijay Bellur 
(cherry picked from commit 16b4936696c8b602243513fbde0b20a1e8417432)