glusterfs.git/xlators/storage, branch v7.0rc0

storage/posix: set the op_errno to proper errno during gfid set

2019-08-22T05:58:47+00:00

In posix_gfid_set, the proper error is not captured in one of
the failure cases.

Change-Id: I1c13f0691a15d6893f1037b3a5fe385a99657e00
Fixes: bz#1736481
Signed-off-by: Raghavendra Bhat 
(cherry picked from commit ed7a3793073670e787063c47e55010fc7c963064)

features/utime: always update ctime at setattr

2019-08-19T11:27:14+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#1739437
Signed-off-by: Kotresh HR

posix/ctime: Fix race during lookup ctime xattr heal

2019-08-19T11:27:14+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#1739436
Change-Id: I930bda192c64c3d49d0aed431ce23d3bc57e51b7
Signed-off-by: Kotresh HR

ctime: Set mdata xattr on legacy files

2019-08-19T11:27:14+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#1739430
Signed-off-by: Kotresh HR

posix : add posix_set_ctime() in posix_ftruncate()

2019-08-09T13:32:12+00:00

>Backport of https://review.gluster.org/#/c/glusterfs/+/22948/
>Change-Id: I0cb5320fea71306e0283509ae47024f23874b53b
>fixes: bz#1723761

Change-Id: I0cb5320fea71306e0283509ae47024f23874b53b
fixes: bz#1739399
Signed-off-by: Jiffin Tony Thottan 
(cherry picked from commit 7d8be567f2f904fc74d0990ebce2e8afbedab918)

posix/ctime: Fix ctime upgrade issue

2019-06-21T11:09:32+00:00

Problem:
On a EC volume, during upgrade from the older version where
ctime feature is not enabled(or not present) to the newer
version where the ctime feature is available (enabled default),
the self heal hangs and doesn't complete.

Cause:
The ctime feature has both client side code (utime) and
server side code (posix). The feature is driven from client.
Only if the client side sets the time in the frame, should
the server side sets the time attributes in xattr. But posix
setattr/fseattr was not doing that. When one of the server
nodes is updated, since ctime is enabled by default, it
starts setting xattr on setattr/fseattr on the updated node/brick.

On a EC volume the first two updated nodes(bricks) are not a
problem because there are 4 other bricks with consistent data.
However once the third brick is updated, the new attribute(mdata xattr)
will cause an inconsistency on metadata on 3 bricks, which
prevents the file to be repaired.

Fix:
Don't create mdata xattr with utimes/utimensat system call.
Only update if already present.

Change-Id: Ieacedecb8a738bb437283ef3e0f042fd49dc4c8c
fixes: bz#1720201
Signed-off-by: Kotresh HR

posix: fix crash in posix_cs_set_state

2019-06-20T11:52:12+00:00

Fixes: bz#1721474
Change-Id: Ic2a53fa3d1e9e23424c6898e0986f80d52c5e3f6
Signed-off-by: Susant Palai

core: fedora 30 compiler warnings

2019-06-18T10:53:49+00:00

warning: ‘%s’ directive argument is null [-Wformat-overflow=]

Change-Id: I69b8d47f0002c58b00d1cc947fac6f1c64e0b295
updates: bz#1193929
Signed-off-by: SheetalPamecha

multiple files: another attempt to remove includes

2019-06-14T16:50:32+00:00

There are many include statements that are not needed.
A previous more ambitious attempt failed because of *BSD plafrom
(see https://review.gluster.org/#/c/glusterfs/+/21929/ )

Now trying a more conservative reduction.
It does not solve all circular deps that we have, but it
does reduce some of them. There is just too much to handle
reasonably (dht-common.h includes dht-lock.h which includes
dht-common.h ...), but it does reduce the overall number of lines
of include we need to look at in the future to understand and fix
the mess later one.

Change-Id: I550cd001bdefb8be0fe67632f783c0ef6bee3f9f
updates: bz#1193929
Signed-off-by: Yaniv Kaul

across: clang-scan: fix NULL dereferencing warnings

2019-06-04T10:30:29+00:00

All these checks are done after analyzing clang-scan report produced
by the CI job @ https://build.gluster.org/job/clang-scan

updates: bz#1622665
Change-Id: I590305af4ceb779be952974b2a36066ffc4865ca
Signed-off-by: Amar Tumballi