[Gluster-users] rebalance and volume commit hash
Jeff Darcy
jdarcy at redhat.com
Tue Jan 17 14:10:26 UTC 2017
> I don't understand why new commit hash is generated for the volume during
> rebalance process? I think it should be generated only during add/remove
> brick events but not during rebalance.
The mismatch only becomes important during rebalance. Prior to that, even
if we've added or removed a brick, the layouts haven't changed and the
optimization is still as valid as it was before. If there are multiple
add/remove operations, we don't need or want to change the hash between
them. Conversely, there are cases besides add/remove brick where we might
want to do a rebalance - e.g. after replace-brick with a brick of a
different size, or to change between total-space vs. free-space weighting.
Changing the hash in add/remove brick doesn't handle these cases, but
changing it at the start of rebalance does.
More information about the Gluster-users
mailing list