Description of problem: The main purpose the brick multiplexing feature tries to serve is to reduce the number of brick processes, hence reusing resources. Currently, we do not have a cap on the number of brick processes that can be run per node with brick multiplexing enabled. The proposal is to have a global option cluster.max-bricks-per-process which can control the number of brick instances to be attached to a single brick process.
upstream patch : https://review.gluster.org/17469
downstream patches : https://code.engineering.redhat.com/gerrit/#/c/111799/ https://code.engineering.redhat.com/gerrit/#/c/111804/
Qatp_Functional validation note: b is the number of bricks existing per node n is cluster.max-bricks-per-process 1)default should allow all bricks to point to same brick process ie on glusterfsd per node irrespective of number of bricks hosted --pass 2)setting to a value say n, must be effective from here on ---->PASS, but will be effective for new vol creates only, existing volumes would have to be restarted, for this effect 3)if bricks on fsd >n(ie which were created before setting value to n), still new bricks must get created on new fsd -->PASS 4)if already b>>n, and offline one of the b, still a new brick create must use a new pid(as long b doesn't go less than n) 5)if b>=n and add-brick must spawn new process 6)if b=n ,remove brick and then add new brick/vol must use existing proc, as b<n with remove brick
validation All the cases mentioned in comment#7 have passed Testversion:3.8.4-35 hence moving this bz to verified Note: The memory consumption and profiling should be check by perf team and if any descripencies there, that can be tracked seperatekly. Functionally, the RFE is healthy and any further issues can be tracked with new bugs. Eg: Some cosmetic bugs were raised as below 1474344 - Allow only the maximum number of bricks supported for cluster.max-bricks-per-process 1474342 - reset cluster.max-bricks-per-process value when brick mux is disabled
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2774