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