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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux