core: run many bricks within one glusterfsd process

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.

Backport of:
> Change-Id: I45059454e51d6f4cbb29a4953359c09a408695cb
> BUG: 1385758
> Reviewed-on: https://review.gluster.org/14763

Change-Id: I4bce9080f6c93d50171823298fdf920258317ee8
BUG: 1418091
Signed-off-by: Jeff Darcy <jdarcy@redhat.com>
Reviewed-on: https://review.gluster.org/16496
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: Shyamsundar Ranganathan <srangana@redhat.com>

1 files changed, 15 insertions, 2 deletions

diff --git a/xlators/mgmt/glusterd/src/glusterd-syncop.c b/xlators/mgmt/glusterd/src/glusterd-syncop.c
index 970aed2924c..07501f2407d 100644
--- a/xlators/mgmt/glusterd/src/glusterd-syncop.c
+++ b/xlators/mgmt/glusterd/src/glusterd-syncop.c
@@ -152,8 +152,6 @@ gd_brick_op_req_free (gd1_mgmt_brick_op_req *req)
         if (!req)
                 return;
 
-        if (strcmp (req->name, "") != 0)
-                GF_FREE (req->name);
         GF_FREE (req->input.input_val);
         GF_FREE (req);
 }
@@ -998,6 +996,21 @@ gd_syncop_mgmt_brick_op (struct rpc_clnt *rpc, glusterd_pending_node_t *pnode,
                         goto out;
                 }
         }
+
+        if (req->op == GLUSTERD_BRICK_TERMINATE) {
+                if (args.op_ret && (args.op_errno == ENOTCONN)) {
+                        /*
+                         * This is actually OK.  It happens when the target
+                         * brick process exits and we saw the closed connection
+                         * before we read the response.  If we didn't read the
+                         * response quickly enough that's kind of our own
+                         * fault, and the fact that the process exited means
+                         * that our goal of terminating the brick was achieved.
+                         */
+                        args.op_ret = 0;
+                }
+        }
+
         if (args.op_ret == 0)
                 glusterd_handle_node_rsp (dict_out, pnode->node, op,
                                           args.dict, op_ctx, errstr,