glusterfs.git/tests/bugs/core, branch v3.12.5

glusterd: Introduce option to limit no. of muxed bricks per process

2017-07-10T04:33:19+00:00

This commit introduces a new global option that can be set to limit
the number of multiplexed bricks in one process.

Usage:
`# gluster volume set all cluster.max-bricks-per-process `

If this option is not set then multiplexing will happen for now
with no limitations set; i.e. a brick process will have as many
bricks multiplexed to it as possible. In other words the current
multiplexing behaviour won't change if this option isn't set to
any value.

This commit also introduces a brick process instance that contains
information about brick processes, like the number of bricks
handled by the process (which is 1 in non-multiplexing cases), list
of bricks, and port number which also serves as an unique identifier
for each brick process instance. The brick process list is
maintained in 'glusterd_conf_t'.

Updates: #151
Change-Id: Ib987d14ab0a4f6034dac01b73a4b2839f7b0b695
Signed-off-by: Samikshan Bairagya 
Reviewed-on: https://review.gluster.org/17469
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee

tests: remove tests/bugs/core/bug-1421590-brick-mux-reuse-ports.t

2017-04-12T07:09:10+00:00

bug-1421590-brick-mux-reuse-ports.t seems to be a bad test to me and here is my
reasoning:

This test tries to check if the ports are reused or not. When a volume is
restarted, by the time glusterd tries to allocate a new port to the one of the
brick processes of the volume there is no guarantee that the older port will be
allocated given the kernel might take some extra time to free up the port between
this time frame. From
https://build.gluster.org/job/regression-test-burn-in/2932/console we can
clearly see that post restart of the volume, glusterd allocated port 49153 &
49155 for brick1 & brick2 respectively but the test was expecting the ports to
be matched with 49155 & 49156 which were allocated before the volume was
restarted.

Change-Id: Id887bf28445261d4de04fc7502e58057659c9512
BUG: 1441035
Signed-off-by: Atin Mukherjee 
Reviewed-on: https://review.gluster.org/17033
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Amar Tumballi

glusterd: hold off volume deletes while still restarting bricks

2017-03-31T03:33:32+00:00

We need to do this because modifying the volume/brick tree while
glusterd_restart_bricks is still walking it can lead to segfaults.
Without waiting we could accidentally "slip in" while attach_brick has
released big_lock between retries and make such a modification.

Change-Id: I30ccc4efa8d286aae847250f5d4fb28956a74b03
BUG: 1432542
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/16927
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee

core: Clean up pmap registry up correctly on volume/brick stop

2017-02-27T22:59:03+00:00

This commit changes the following:
1. In glusterfs_handle_terminate, send out individual pmap signout
requests to glusterd for every brick.
2. Add another parameter to glusterfs_mgmt_pmap_signout function to
pass the brickname that needs to be removed from the pmap registry.
3. Make sure pmap_registry_search doesn't break out from the loop
iterating over the list of bricks per port if the first brick entry
corresponding to a port is whitespaced out.
4. Make sure the pmap registry entries are removed for other
daemons like snapd.

Change-Id: I69949874435b02699e5708dab811777ccb297174
BUG: 1421590
Signed-off-by: Samikshan Bairagya 
Reviewed-on: https://review.gluster.org/16689
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Gaurav Yadav 
Reviewed-by: Jeff Darcy

glusterd: take conn->lock around operations on conn->reconnect

2017-02-18T06:59:10+00:00

Failure to do this could lead to a race in which a timer would be
removed twice concurrently, corrupting the timer list (because
gf_timer_call_cancel has no internal protection against this) and
possibly causing a crash.

Change-Id: Ic1a8b612d436daec88fd6cee935db0ae81a47d5c
BUG: 1421721
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/16662
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee

tests: Fix spurious failure in bug-1402841.t-mt-dir-scan-race.t

2016-12-19T09:31:52+00:00

Check that shd is up before executing 'volume heal' command

Change-Id: Ib510a5de06d732fd3a738e90fa16376698479897
BUG: 1405554
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/16169
Smoke: Gluster Build System 
Reviewed-by: Ravishankar N 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Raghavendra Talur

syncop: fix conditional wait bug in parallel dir scan

2016-12-09T10:24:21+00:00

Problem:
The issue as seen by the user is detailed in the BZ but what is
happening is if the no. of items in the wait queue == max-qlen,
syncop_mt_dir_scan() does a pthread_cond_wait until the launched
synctask workers dequeue the queue. But if for some reason the worker
fails, the queue is never emptied due to which further invocations of
syncop_mt_dir_scan() are blocked forever.

Fix: Made some changes to _dir_scan_job_fn

- If a worker encounters error while processing an entry, notify the
  readdir loop in syncop_mt_dir_scan() of the error but continue to process
  other entries in the queue, decrementing the qlen as and when we dequeue
  elements, and ending only when the queue is empty.

- If the readdir loop in syncop_mt_dir_scan() gets an error form the
  worker, stop the readdir+queueing of further entries.

Change-Id: I39ce073e01a68c7ff18a0e9227389245a6f75b88
BUG: 1402841
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/16073
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri

logging: Fix per xl log level

2016-08-15T12:04:15+00:00

Currently per xlator loglevel setting doesn't work, due to the
flaw in loglevel checking. Fix the same.

Per xlator logging can be set using the below command:

Eg: setfattr -n trusted.glusterfs.patchy-md-cache.set-log-level -v TRACE /mnt/glusterfs/0

Change-Id: I8ff1d15bd5693b6f682d99bee22a4bbb5eee646c
BUG: 1362520
Signed-off-by: Poornima G 
Reviewed-on: http://review.gluster.org/15071
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Niels de Vos 
Reviewed-by: Jeff Darcy

libglusterfs: fix glusterd statedump crash

2016-08-04T15:44:09+00:00

commit 3c04a91 removed setting typeStr to NULL if num_allocs is set to 0, this
has caused this regression. Code has been put back like earlier and to avoid
statedump printing all the NULL values check is modified to see skip the records
if num_allocs is 0 instead of total_allocs

Change-Id: Ib8bcc2fba908e88cf52b641c3f6bcba74f5e667c
BUG: 1359190
Signed-off-by: Atin Mukherjee 
Reviewed-on: http://review.gluster.org/14987
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: N Balachandran 
Reviewed-by: Prashanth Pai 
Reviewed-by: Jeff Darcy

io-stats: Fix io-stat dump to dump at all levels

2016-06-15T17:38:00+00:00

Previous commit to fix the bug, where io-stat-dump was overwriting
the dump file when the client and a brick was on the same host,
failed to consider the existing behaviour where io-stats can
help generate closely correlated set of stats across clients
and bricks, by triggering the dump using the same command.

This was introduced in commit:
0facb11220aea20a6573b656785922219c9650cf

Further, by limiting the first io-stat to unwind the dump request,
there is no way to trigger other io-stat xlators in the stack to
dump their stat information.

This bug hence is being fixed by this commit keeping the
following in mind,
- We need to trigger io-stat-dump for all instances in the
graph when this attr is set
- We need to write the output to different files, so that
they do not overwrite each others data
- We need to prevent this xattr from being set on the path
that is used to trigger the io-stat-dump information

Change-Id: I31ec380f0d85e10313a9d7b977da0e1ec74638a6
BUG: 1322825
Signed-off-by: Shyam 
Reviewed-on: http://review.gluster.org/14552
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Ravishankar N 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy