[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