glusterfs.git/xlators/storage/posix/src, branch v7.7

cluster/afr: Prioritize ENOSPC over other errors

2020-06-22T05:42:20+00:00

Problem:
In a replicate/arbiter volume if file creations or writes fails on
quorum number of bricks and on one brick it is due to ENOSPC and
on other brick it fails for a different reason, it may fail with
errors other than ENOSPC in some cases.

Fix:
Prioritize ENOSPC over other lesser priority errors and do not set
op_errno in posix_gfid_set if op_ret is 0 to avoid receiving any
error_no which can be misinterpreted by __afr_dir_write_finalize().

Also removing the function afr_has_arbiter_fop_cbk_quorum() which
might consider a successful reply form a single brick as quorum
success in some cases, whereas we always need fop to be successful
on quorum number of bricks in arbiter configuration.

Change-Id: I106e267f8b9451f681022f1cccb410d9bc824c08
Fixes: #1254
Signed-off-by: karthik-us 
(cherry picked from commit fa63b45ca5edf172b1b89b28b5db3c5129cc57b6)

tests: skip tests on absence of reflink in xfs

2020-06-10T10:27:33+00:00

Fixes: #1223
Change-Id: I36cb72d920ffd77405051546615c5262c392daef
Signed-off-by: Pranith Kumar K

posix: log aio_error return codes in posix_fs_health_check

2020-04-14T14:00:17+00:00

Problem: Sometime brick is going down to health check thread is
         failed without logging error codes return by aio system calls.
         As per aio_error man page it returns a positive error number
         if the asynchronous I/O operation failed.

Solution: log aio_error return codes in error message

> Change-Id: I2496b1bc16e602b0fd3ad53e211de11ec8c641ef
> (Cherry picked from commit 032862fa3944fc7152140aaa13cdc474ae594a51)
> (Reviwed on upstream link https://review.gluster.org/#/c/glusterfs/+/23284/
> Signed-off-by: Mohit Agrawal 

Change-Id: I2496b1bc16e602b0fd3ad53e211de11ec8c641ef
Fixes: #1168
Signed-off-by: Mohit Agrawal

multiple: fix bad type cast

2020-03-16T08:21:00+00:00

When using inode_ctx_get() or inode_ctx_set(), a 'uint64_t *' is expected.
In many cases, the value to retrieve or store is a pointer, which will be
of smaller size in some architectures (for example 32-bits). In this case,
directly passing the address of the pointer casted to an 'uint64_t *' is
wrong and can cause memory corruption.

Backport of:
> Change-Id: Iae616da9dda528df6743fa2f65ae5cff5ad23258
> Signed-off-by: Xavi Hernandez 
> Fixes: bz#1785611

Change-Id: Iae616da9dda528df6743fa2f65ae5cff5ad23258
Signed-off-by: Xavi Hernandez 
Fixes: bz#1785323

ctime/rebalance: Heal ctime xattr on directory during rebalance

2019-09-16T10:54:21+00:00

After add-brick and rebalance, the ctime xattr is not present
on rebalanced directories on new brick. This patch fixes the
same.

Note that ctime still doesn't support consistent time across
distribute sub-volume.

This patch also fixes the in-memory inconsistency of time attributes
when metadata is self healed.

Backport of:

 > Patch: https://review.gluster.org/23127/
 > Change-Id: Ia20506f1839021bf61d4753191e7dc34b31bb2df
 > BUG: 1734026
 > Signed-off-by: Kotresh HR 
(cherry picked from commit 304640e55c0f3c6d15f4e230dc6376e4f5020fea)

Change-Id: Ia20506f1839021bf61d4753191e7dc34b31bb2df
Signed-off-by: Kotresh HR 
fixes: bz#1752429

[RFC] change get_real_filename implementation to use ENOATTR instead of ENOENT

2019-09-03T13:21:37+00:00

get_real_filename is implemented as a virtual extended attribute to help
Samba implement the case-insensitive but case preserving SMB protocol
more efficiently. It is implemented as a getxattr call on the parent directory
with the virtual key of "get_real_filename:" by looking for a
spelling with different case for the provided file/dir name ()
and returning this correct spelling as a result if the entry is found.
Originally (05aaec645a6262d431486eb5ac7cd702646cfcfb), the
implementation used the ENOENT errno to return the authoritative answer
that  does not exist in any case folding.

Now this implementation is actually a violation or misuse of the defined
API for the getxattr call which returns ENOENT for the case that the dir
that the call is made against does not exist and ENOATTR (or the synonym
ENODATA) for the case that the xattr does not exist.

This was not a problem until the gluster fuse-bridge was changed
to do map ENOENT to ESTALE in 59629f1da9dca670d5dcc6425f7f89b3e96b46bf,
after which we the getxattr call for get_real_filename returned an
ESTALE instead of ENOENT breaking the expectation in Samba.

It is an independent problem that ESTALE should not leak out to user
space but is intended to trigger retries between fuse and gluster.
But nevertheless, the semantics seem to be incorrect here and should
be changed.

This patch changes the implementation of the get_real_filename virtual
xattr to correctly return ENOATTR instead of ENOENT if the file/directory
being looked up is not found.

The Samba glusterfs_fuse vfs module which takes advantage of the
get_real_filename over a fuse mount will receive a corresponding change
to map ENOATTR to ENOENT. Without this change, it will still work
correctly, but the performance optimization for nonexisting files is
lost. On the other hand side, this change removes the distinction
between the old not-implemented case and the implemented case.
So Samba changed to treat ENOATTR like ENOENT will not work correctly
any more against old servers that don't implement get_real_filename.
I.e. existing files will be reported as non-existing

Change-Id: I971b427ab8410636d5d201157d9af70e0d075b67
fixes: bz#1745914
Signed-off-by: Michael Adam 
(cherry picked from commit dc1b87fcfef08c9497b0c02b2410c9d18bbc2dba)

ctime: Fix ctime issue with utime family of syscalls

2019-08-27T18:25:52+00:00

When atime|mtime is updated via utime family of syscalls,
ctime is not updated. This patch fixes the same.

Backport of:
 > Patch: https://review.gluster.org/23177/
 > Change-Id: I7f86d8f8a1e06a332c3449b5bbdbf128c9690f25
 > BUG: 1738786
 > Signed-off-by: Kotresh HR 
(cherry picked from commit 95f71df31dc73d85df722b0e7d3a7eb1e0237e7f)

Change-Id: I7f86d8f8a1e06a332c3449b5bbdbf128c9690f25
fixes: bz#1746142
Signed-off-by: Kotresh HR

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