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 _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
