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
>>> 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.
>>
>
> 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 [1], and based on
other DHT work we can check and see when we can accommodate this (or as
always patches are welcome).
[1] https://github.com/gluster/glusterfs/issues/new
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>