On 01/17/2017 11:40 AM, Piotr Misiak wrote:
17 sty 2017 17:10 Jeff Darcy <jda...@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@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users
