glusterfs.git/xlators/features, branch v9dev

features/utime: Don't access frame after stack-wind

2020-04-03T07:46:44+00:00

Problem:
frame is accessed after stack-wind. This can lead to crash
if the cbk frees the frame.

Fix:
Use new frame for the wind instead.

Updates: #832
Change-Id: I64754609f1114b0bbd4d1336fa81a56f2cca6e03
Signed-off-by: Pranith Kumar K

add clean local after grant lock

2020-04-01T06:34:24+00:00

found by flock test, without correct ref number of fd,
lock will not be correctly released.

Fixes: bz#1779089
Change-Id: I3e466b17c852eb219c8778e43af8ad670a8449cc
Signed-off-by: l17zhou

Marker: Logically deadcode found by coverity

2020-03-31T12:47:00+00:00

Have removed the deadcode found by the coverity id:1356503

Change-Id: Ieaa41e864538fb82dc967b4a214d4db09e267098
Updates: #1060
Signed-off-by: Hari Gowtham

core[brick_mux]: brick crashed when creating and deleting volumes over time

2020-03-27T15:19:20+00:00

Problem: In brick_mux environment, while volumes are created/stopped in a loop
         after running a long time the main brick is crashed.The brick is crashed
         because the main brick process was not cleaned up memory for all objects
         at the time of detaching a volume.
         Below are the objects that are missed at the time of detaching a volume
         1) xlator object for a brick graph
         2) local_pool for posix_lock xlator
         3) rpc object cleanup at quota xlator
         4) inode leak at brick xlator

Solution: To avoid the crash resolve all leak at the time of detaching a brick
Change-Id: Ibb6e46c5fba22b9441a88cbaf6b3278823235913
updates: #977
Signed-off-by: Mohit Agrawal

features/shard: Fix crash during shards cleanup in error cases

2020-03-26T04:44:39+00:00

A crash is seen during a reattempt to clean up shards in background
upon remount. And this happens even on remount (which means a remount
is no workaround for the crash).

In such a situation, the in-memory base inode object will not be
existent (new process, non-existent base shard).
So local->resolver_base_inode will be NULL.

In the event of an error (in this case, of space running out), the
process would crash at the time of logging the error in the following line -

        gf_msg(this->name, GF_LOG_ERROR, local->op_errno, SHARD_MSG_FOP_FAILED,
               "failed to delete shards of %s",
               uuid_utoa(local->resolver_base_inode->gfid));

Fixed that by using local->base_gfid as the source of gfid when
local->resolver_base_inode is NULL.

Change-Id: I0b49f2b58becd0d8874b3d4b14ff8d92a89d02d5
Fixes: #1127
Signed-off-by: Krutika Dhananjay

worm-xlator: fix newly introduced coverity issue

2020-03-20T07:41:12+00:00

This patch fixes CID: 1420405

updates: #1060

Change-Id: I0524e999fa1d36ed5a713eabf65482c04ad43a1a
Signed-off-by: Sunny Kumar

WORM-Xlator: Initial write of a file succeeds if auto-commit-period 0

2020-03-17T04:24:14+00:00

If worm-file-level enabled and auto-commit-period 0 an initial write
of a file (e.g. $ echo test >> file1.txt) would lead to an zero byte
file because the WORM xlator immediately WORMed the file when it was
created.

To avoid this we move the setting of trusted.worm_file from
worm_create_cbk to worm_release . This means that this xattr will set
when the filehandle is closed and all initial WRITE FOPs succeed.

Finally we also perform gf_worm_state_transition in worm_release to
ensure that the file will be immediately WORMed after the file handle
was closed.

Change-Id: I5d02e18975b646ca1a27ed41d836e9d0dc333204
Fixes: bz#1808421
Signed-off-by: David Spisla

utime: resolve an issue of permission denied logs

2020-03-13T12:15:21+00:00

In case where uid is not set to be 0, there are possible errors
from acl xlator. So, set `uid = 0;` with pid indicating this is
set from UTIME activity.

The message "E [MSGID: 148002] [utime.c:146:gf_utime_set_mdata_setxattr_cbk] 0-dev_SNIP_data-utime: dict set of key for set-ctime-mdata failed [Permission denied]" repeated 2 times between [2019-12-19 21:27:55.042634] and [2019-12-19 21:27:55.047887]

Change-Id: Ieadf329835a40a13ac0bf908dac776e66954466c
Fixes: #832
Signed-off-by: Amar Tumballi

feature/changelog: Avoid thread creation if xlator is not enabled

2020-02-09T12:42:56+00:00

Problem:
Changelog creates threads even if the changelog is not enabled

Background:
Changelog xlator broadly does two things
  1. Journalling - Cosumers are geo-rep and glusterfind
  2. Event Notification for registered events like (open, release etc) -
     Consumers are bitrot, geo-rep

The existing option "changelog.changelog" controls journalling and
there is no option to control event notification and is enabled by
default. So when bitrot/geo-rep is not enabled on the volume, threads
and resources(rpc and rbuf) related to event notifications consumes
resources and cpu cycle which is unnecessary.

Solution:
The solution is to have two different options as below.
 1. changelog-notification : Event notifications
 2. changelog : Journalling

This patch introduces the option "changelog-notification" which is
not exposed to user. When either bitrot or changelog (journalling)
is enabled, it internally enbales 'changelog-notification'. But
once the 'changelog-notification' is enabled, it will not be disabled
for the life time of the brick process even after bitrot and changelog
is disabled. As of now, rpc resource cleanup has lot of races and is
difficult to cleanup cleanly. If allowed, it leads to memory leaks
and crashes on enable/disable of bitrot or changelog (journal) in a
loop. Hence to be safer, the event notification is not disabled within
lifetime of process once enabled.

Change-Id: Ifd00286e0966049e8eb9f21567fe407cf11bb02a
Updates: #475
Signed-off-by: Mohit Agrawal

bitrot: Make number of signer threads configurable

2020-02-07T06:30:19+00:00

The number of signing process threads (glfs_brpobj)
is set to 4 by default. The recommendation is to set
it to number of cores available. This patch makes it
configurable as follows

gluster vol bitrot  signer-threads 

fixes: bz#1797869
Change-Id: Ia883b3e5e34e0bc8d095243508d320c9c9c58adc
Signed-off-by: Kotresh HR