[Gluster-users] rebalance and volume commit hash

[Piotr Misiak]

Do you think that is wise to run rebalance process manually on every
brick with the actual commit hash value?

I didn't do anything with bricks after previous rebalance run and I have
cluster.weighted-rebalance=off.

My problem is that I have a very big directory structure (millions of
directories and files) and I haven't ever completed rebalance process
once, because it will take I guess weeks or months. I'd like to speed it
up a bit by not generating new commit hash for volume during new
rebalance run. Then directories rebalanced in the previous run will be
untouched during the new run. Is it possible?

Thanks


Piotr Misiak
Senior Cloud Engineer
CloudFerro Sp. z o.o.

On 17.01.2017 15:10, Jeff Darcy wrote:
>> 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.