glusterfs.git/xlators, branch v3.12.2

cluster/ec: Improve performance with xattrop update

2017-10-12T18:52:34+00:00

Existing EC code updates the xattr on the subvolume
in a sequential pattern resulting in very poor performance.

With this fix EC now updates the xattr on the subvolume
in parallel which improves the xattr update performance.

>BUG: 1445663
>Change-Id: I3fc40d66db0b88875ca96a9fa01002ba386c0486
>Signed-off-by: Sunil Kumar Acharya 

BUG: 1499150
Change-Id: I3fc40d66db0b88875ca96a9fa01002ba386c0486
Signed-off-by: Sunil Kumar Acharya

glusterd:Marking all the brick status as stopped when a process goes down in brick multiplexing

2017-10-12T18:49:37+00:00

In brick multiplexing environment, if a brick process goes down
i.e., if we kill it with SIGKILL, the status of the brick for which
the process came up for the first time is only changing to stopped.
all other brick statuses are remain started. This is happening because
the process was killed abruptly using SIGKILL signal and signal
handler wasn't invoked and further cleanup wasn't triggered.

When we try to start a volume using force, it shows error saying
"Request timed out", since all the brickinfo->status are still in
started state, we're waiting for one of the brick process to come up
which never going to happen since the brick process was killed.

To resolve this, In the disconnect event, We are checking all the
processes that whether the brick which got disconnected belongs the
process. Once we get the process we are calling a function named
glusterd_mark_bricks_stopped_by_proc() and sending brick_proc_t object as
an argument.

From the glusterd_brick_proc_t we can get all the bricks attached
to that process. but these are duplicated ones. To get the original
brickinfo we are reading volinfo from brick. In volinfo we will have
original brickinfo copies. We are changing brickinfo->status to
stopped for all the bricks.

>Change-Id: Ifb9054b3ee081ef56b39b2903ae686984fe827e7
>BUG: 1499509
>Signed-off-by: Sanju Rakonde 
>Reviewed-on: https://review.gluster.org/#/c/18444/
>Smoke: Gluster Build System 
>CentOS-regression: Gluster Build System 
>Reviewed-by: Atin Mukherjee 
>cherry picked from commit 9422446d72bc054962d72ace9912ecb885946d49)

Change-Id: Ifb9054b3ee081ef56b39b2903ae686984fe827e7
BUG: 1501154
Signed-off-by: Sanju Rakonde

cluster/afr: Make choose-local "reconfigurable"

2017-10-12T18:46:10+00:00

        Backport of:
        > Change-Id: Ibab292ba705d993b475cd0303fb3318211fb2500
        > Reviewed-on: https://review.gluster.org/18026
        > BUG: 1480525
        > cherry-picked from commit 1e2d6537875d16b783e3c50ada7ee61487c6d796

With this change, enabling choose-local (which means its state makes
transition from "off" to "on") will be effective after the first
gfid-lookup on "/" since volume-set was executed.

Change-Id: Ibab292ba705d993b475cd0303fb3318211fb2500
BUG: 1501022
Signed-off-by: Krutika Dhananjay

fuse/readdirp: Remove need_lookup from fuse_readdirp_cbk

2017-10-12T18:41:46+00:00

background: Various xlators used to populate their ctx, on
an explicit lookup. That means without a lookup, the translator will have
either null or stale data to function. E.g. dht would depend on lookup to
create linkto files on the correct node/hashed subvol, afr would rely on
this lookup to heal pending data/metadata etc.

So to complete above actions a lookup used to be issued on files,
even their inode was populated on a readdirp_cbk. This was done
by setting the need_lookup flag on all the files those were read
on readdirp fop.

We tried a small test on "ACL client". For listing 50k files on root
itself, it took around 50seconds with readdirp enabled while
the same operation took 5-6 seconds with readdirp disabled. Both the
times md-cache was enabled.

We observed that on the 1st test case (readdirp enabled), post readdirp
a getxattr is done. The number of getxattr depends on the number of acl
xattrs (I saw requests on these two: system.posix_acl_default,
system.posix_acl_access). Since need_lookup flag is set, during fuse_resolve
a nameless lookup is executed on the inode(getxattr being inode operation,
hence the nameless lookup). Since md-cache does not serve nameless lookup,
a network hop is needed for each file, costing the time.

With readdirp disabled, the getxattrs are served from md-cache itself(note:
we are discussing the 2nd attempt of ls -l use case).

_Current affairs around need of lookup for a file to populate it's ctx_:

For the xlators on client stack we discussed quite extensively about the need
for a lookup fop post readdirp in all three cluster translators - afr, EC and
dht. EC and dht don't really need a nameless lookup post readdirp. For afr too,
the need for lookup was negated with patch (http://review.gluster.org/6010 - AFRV2),
where  afr added a function called afr_inode_refresh() which does a lookup and
populates its inode context in case a FOP came to AFR without a lookup being issued
prior to it.

We ran a thread on gluster-devel asking for feedback on the need of explicit lookup
post readdirp. For responses refer [1]. Refer [2] for discussions happened on gerrit.
After gathering inputs from [1] and [2], it looks like there is no xlator in
current state that requires an explicit lookup post readdirp to function properly.

* A separate similar patch will be sent for gfapi/nfs/nfs-ganesha.

Note: Only file's inode is built with readdirp.

[1] http://lists.gluster.org/pipermail/gluster-devel/2017-August/053505.html
[2] https://review.gluster.org/#/c/17985/

> Change-Id: Ie1d68ce7bea5e1f8a1fab9a62217f478322554f5
> BUG: 1492996
> Signed-off-by: Susant Palai 

Change-Id: Ie1d68ce7bea5e1f8a1fab9a62217f478322554f5
BUG: 1499123
Signed-off-by: Susant Palai

cluster/dht: Don't store the entire uuid for subvols

2017-10-12T18:25:29+00:00

Comparing the uuid string of the local node against that stored in the
local_subvol information is inefficient, especially as it is
done for every file to be migrated. The code has now been changed
to set the value of info to 1 if the nodeuuid is that of the node
making the comparison so this becomes an integer comparison.

> BUG: 1451434
> Signed-off-by: N Balachandran 
> https://review.gluster.org/#/c/17851

(cherry picked from commit c4a608799a577a4f38139f6bb8a47da8efb0fec3)
Change-Id: I7491d59caad3b71dbf5facc94dcde0cd53962775
BUG: 1500472
Signed-off-by: N Balachandran

glusterd: disallow replace brick for dist only volumes

2017-10-12T05:38:57+00:00

Allowing replace-brick on dist only volumes will lead to data loss. This
patch blocks replace brick commit force to fail if a volume is dist
only.

Also removing tests/basic/pump.t as its of no use as per the discussion
in
http://lists.gluster.org/pipermail/gluster-devel/2017-September/053652.html

>Reviewed-on: https://review.gluster.org/18226
>Smoke: Gluster Build System 
>Reviewed-by: N Balachandran 
>CentOS-regression: Gluster Build System 
>(cherry picked from commit 7f70d38b66ce755f848ff0197814457a28b321df)

Change-Id: Iabb0c16f865f3fc361b64a19bfcf0c0fbb5c2682
BUG: 1493975
Signed-off-by: Atin Mukherjee

cli/afr: gluster volume heal info "healed" command output is not appropriate

2017-10-11T10:02:57+00:00

Problem: "gluster volume heal info [healed] [heal-failed]" command
          output on terminal is not appropriate in case of down any volume.

Solution: To make message more appropriate change the condition
          in function "gd_syncop_mgmt_brick_op".

Test : To verify the fix followed below procedure
       1) Create 2*3 distribute replicate volume
       2) set self-heal daemon off
       3) kill two bricks (3, 6)
       4) create some file on mount point
       5) bring brick 3,6 up
       6) kill other two brick (2 and 4)
       7) make self heal daemon on
       8) run "gluster v heal "

Note: After apply the patch options (healed | heal-failed) will deprecate
      from command line.

> BUG: 1388509
> Change-Id: I229c320c9caeb2525c76b78b44a53a64b088545a
> Signed-off-by: Mohit Agrawal 
> (Cherry pick from commit d1f15cdeb609a1b720a04a502f7a63b2d3922f41)

BUG: 1500662
Change-Id: I229c320c9caeb2525c76b78b44a53a64b088545a
Signed-off-by: Mohit Agrawal

glusterd: fix invalid memory reference returned

2017-10-10T05:35:06+00:00

> BUG: 1490897
> Reviewed-on: https://review.gluster.org/18263
> Smoke: Gluster Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Jeff Darcy 
> Reviewed-by: Gaurav Yadav 

Change-Id: I0823c7b33060b48040c1d86ad346a5f6e15bc190
BUG: 1491178
Signed-off-by: Xavier Hernandez

afr: heal gfid as a part of entry heal

2017-10-10T05:33:15+00:00

Problem:
If a brick crashes after an entry (file or dir) is created but before
gfid is assigned, the good bricks will have pending entry heal xattrs
but the heal won't complete because afr_selfheal_recreate_entry() tries
to create the entry again and it fails with EEXIST.

Fix:
We could have fixed posx_mknod/mkdir etc to assign the gfid if the file
already exists but the right thing to do seems to be to trigger a lookup
on the bad brick and let it heal the gfid instead of winding an
mknod/mkdir in the first place.

(cherry picked from commit 20fa80057eb430fd72b4fa31b9b65598b8ec1265)
Change-Id: I82f76665a7541f1893ef8d847b78af6466aff1ff
BUG: 1499202
Signed-off-by: Ravishankar N

glusterd: fix client io-threads option for replicate volumes

2017-10-09T12:21:08+00:00

Backport of https://review.gluster.org/#/c/18430/

Problem:
Commit ff075a3d6f9b142911d25c27fd209838782bfff0 disabled loading
client-io-threads for replicate volumes (it was set to on by default in
commit e068c1997314046658dd502e9118dab32decf879) due to performance
issues but in doing so, inadvertently failed to load the xlator even if
the user explicitly enabled the option using the volume set command.
This was despite returning returning sucess for the volume set.

Fix:
Modify the check in perfxl_option_handler() and add checks in volume
create/add-brick/remove-brick code paths, tying it all to
GD_OP_VERSION_3_12_2.

Change-Id: Ib612973a999a7da818cc926f5c2601b1f0794fcf
BUG: 1499158
Signed-off-by: Ravishankar N