[Gluster-devel] [Gluster-users] Proposal to deprecate replace-brick for "distribute only" volumes

Shyam srangana at redhat.com
Wed Mar 29 15:18:50 UTC 2017


On 03/16/2017 08:59 AM, Joe Julian wrote:
>> In the last few releases, we have changed replace-brick command such
>> that it can be called only with "commit force" option. When invoked,
>> this is what happens to the volume:
>>
>> a. distribute only volume: the given brick is replaced with a empty
>> brick with 100% probability of data loss.
>> b. distribute-replicate: the given brick is replaced with a empty
>> brick and self heal is triggered. If admin is wise enough to monitor
>> self heal status before another replace-brick command, data is safe.
>> c. distribute-disperse: same as above in distribute-replicate
>>
>> My proposal is to fully deprecate replace-brick command for
>> "distribute only" volumes. It should print out a error "The right way
>> to replace brick for distribute only volume is to add brick, wait for
>> rebalance to complete and remove brick" and return a "-1".

I am responding late, assuming this is still not done or WIP. Correct me 
if I am wrong.

Yes, we need the above. As it really does not make any sense in the way 
the current (replace brick) command is structured to lose a pure 
distribute brick.

>>
>>
>>
>>
>> It makes sense.
>> I just don't see any use of add-brick before remove-brick except the
>> fact that it will
>> help to keep the overall storage capacity of volume intact .
>> What is the guarantee that the files on the brick which we want to
>> replace
>> would migrate to added brick?
>>
>> If a brick, which we want to replace, is healthy and we just want to
>> replace it then perhaps we should provide
>> a command to copy those files to new brick and then remove the old
>> brick.
>
> We used to have a command that did just that. It was replace-brick.

This involves some rebalance trickery IMO (if we leverage that to 
replace the brick in a distribute only volume), which we do not have. I 
would suggest a github issue be added for such support, and take in the 
prevention of current replace-brick on distribute only volumes as the 
first priority (for obvious reasons as stated by talur).

Shyam


More information about the Gluster-devel mailing list