> 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.
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.
> 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?I'm pretty sure that trying to rebalance on each brick separately will not work correctly. Rebalancing smaller pieces of the directory hierarchy separately, by issuing the appropriate setxattr calls on them instead of using the CLI, *might* work. Either way, I think the DHT experts could provide a better answer.