| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the mux tests, set a trap to catch test exit and
call cleanup. This will cause cleanup to be invoked twice
in case the test times out, or even otherwise, as include.rc
also sets a trap to cleanup on exit (TERM and others).
This leads to the tarballs generated on failures for these
tests to be empty and does not aid debugging.
This patch corrects this pattern across the tests to the
more standard cleanup at the end.
Fixes: bz#1615037
Change-Id: Ib83aeb09fac2aa591b390b9fb9e1f605bfef9a8b
Signed-off-by: ShyamsundarR <srangana@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: glusterd start a volume as a separate process instead of
attaching with the already running process if volume option has
different brick-log-level. There is no functionality impact on a brick
if the option has different brick-log-level so glusterd
should attach a brick with the already running process.
Solution: Ignore brick-log-level option in unsafe_option
BUG: 1599628
Change-Id: I72638ff2026fcd9332bc38e1144b1ef4a708820b
fixes: bz#1599628
Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When brick-multiplexing is enabled, and
"cluster.max-bricks-per-process" isn't explicitly set, multiplexing
happens without any limit set. But the default value set for that
tunable is 1, which is confusing. This commit sets the default
value to 0, and prevents the user from being able to set this value
to 1 when brick-multiplexing is enbaled. The default value of 0
denotes that brick-multiplexing can happen without any limit on the
number of bricks per process.
Change-Id: I4647f7bf5837d520075dc5c19a6e75bc1bba258b
BUG: 1472417
Signed-off-by: Samikshan Bairagya <samikshan@gmail.com>
Reviewed-on: https://review.gluster.org/17819
Smoke: Gluster Build System <jenkins@build.gluster.org>
Reviewed-by: Atin Mukherjee <amukherj@redhat.com>
CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
|
|
|
This patch adds support for multiple brick translator stacks running
in a single brick server process. This reduces our per-brick memory usage by
approximately 3x, and our appetite for TCP ports even more. It also creates
potential to avoid process/thread thrashing, and to improve QoS by scheduling
more carefully across the bricks, but realizing that potential will require
further work.
Multiplexing is controlled by the "cluster.brick-multiplex" global option. By
default it's off, and bricks are started in separate processes as before. If
multiplexing is enabled, then *compatible* bricks (mostly those with the same
transport options) will be started in the same process.
Change-Id: I45059454e51d6f4cbb29a4953359c09a408695cb
BUG: 1385758
Signed-off-by: Jeff Darcy <jdarcy@redhat.com>
Reviewed-on: https://review.gluster.org/14763
Smoke: Gluster Build System <jenkins@build.gluster.org>
NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
