On 20 January 2017 at 01:15, Shyam <srang...@redhat.com> wrote: > > > 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 > > Yes , please do raise an issue and we can take a look at what can be done here.
> > _______________________________________________ >> 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 >
_______________________________________________ Gluster-users mailing list Gluster-users@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-users