mirror of
https://github.com/gluster/glusterd2.git
synced 2026-02-05 21:45:43 +01:00
5814720454
The implementation is an extension to brick-multiplexing. The max-bricks-per-process is being monitored by using entries in pmap corresponding to a particular port. So, If a brick needs to be multiplexed following are the series of steps that needs to be followed. The following are the genralised sets of steps - - look into all started volumes with same options as the current volume(one by one) - traverse through all local bricks of taregtVolume - find the port of the local brick by using its path - look for number of entries in pmap corresponding to particular port No. and count num of bricks already attached to that port - If the number of bricks attached to a port is less that max-bricks-per-process constraint - Then we have our target brick or repeat from step 1 until all targetVolumes are covered. - Since current volume is not considered into started volumes list, so if we don't have any target brick yet from any of the started volumes then - look for any target brick in the current volume - If even the current volume doesn't have any target brick then - start seperate glusterfsd. Cases Handles in this PR and approach followed - 1- If no started volume already present - check current volume for target brick - if taregt brick not found, start seperate glusterfsd 2- If atleast one started volume present - if Target volume found, out of all the started volumes * if target brick found, attach to the brick * if taregt brick not found, look through other taregt volumes * if still target brick not found, look into current volume * if still taregt brick not found, start seperate glusterfsd process - if target Volume not found * look into current volume for any target bricks * if taregt brick not found, start seperate glusterfsd Signed-off-by: Vishal Pandey <vpandey@redhat.com>