[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