[Gluster-users] rebalance and volume commit hash
srangana at redhat.com
Thu Jan 19 19:45:08 UTC 2017
On 01/17/2017 11:40 AM, Piotr Misiak wrote:
> 17 sty 2017 17:10 Jeff Darcy <jdarcy at redhat.com> napisał(a):
>>> 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
>>> 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.
> Is it possible to start rebalancing from a particular subdirecory? Do you know how? It would be very useful for me.
Rebalancing a sub-directory is not supported.
Having said that, if we were to support it, then we could rebalance at a
sub-directory level and retain the volume commit hash as is. The commit
hash states truth about a directory and its immediate children, so
retaining the volume commit-hash when rebalancing a sub-dir is a
possibility (needs a little more thought, but at the outset is possible).
Further, for your case, it looks like rebalance takes a long time. So
one other option could be to just create the link-to files (or complete
a tree walk and lookup everything) and not move any data. This should be
faster than moving data around, and provides enough pre-condition for
the lookup-optimize to function. Of course, this will not balance the
data, so if are really looking to expand the volume size a full
rebalance maybe required.
May I request a couple of issues raised for these here , and based on
other DHT work we can check and see when we can accommodate this (or as
always patches are welcome).
> Gluster-users mailing list
> Gluster-users at gluster.org
More information about the Gluster-users