[Gluster-devel] Feature review: Improved rebalance performance

Xavier Hernandez xhernandez at datalab.es
Wed Jul 2 10:25:18 UTC 2014


On Tuesday 01 July 2014 10:59:08 Shyamsundar Ranganathan wrote:
> > As I see it, rebalance on access should be a complement to normal
> > rebalance
> > to
> > keep the volume _more_ balanced (keep accessed files on the right brick to
> > avoid unnecessary delays due to global lookups or link file redirections),
> > but
> > it can not assure that the volume is fully rebalanced.
> 
> True, except in the case where we ensure link files are created during
> rebalance _changed_.

I think we are talking about slightly different things. It seems that you 
consider that a file not placed in the right brick but having a link in the 
right brick is already balanced. I consider that this is not really balanced.

A link file is good to avoid unnecessary global lookups, but they still incur 
in a performance hit and a future rebalance will have more work than expected 
if those files are not placed where they should be. I think it's important to 
keep as few of these "bad located" files as possible at all times. This is the 
reason I'm saying to use an index to track small changes (i.e. renames) and be 
able to identify and move them very fast. This is basically useful when the 
volume is considered stable (i.e. not adding nor removing a brick and the last 
full rebalance has finished).

Xavi


More information about the Gluster-devel mailing list