Hi,
With Change-Id:Ieba9a7071829d51860b7c131982f12e0136b9855 , dht
itansform/deitransform was improved to encode 64-bit brick offset along
with the brick-id in the global d_off.
More details regarding this change are in :
http://review.gluster.org/#/c/4711/
But now with afr using the same
Hi Shyam,
On Thursday 26 June 2014 14:41:13 Shyamsundar Ranganathan wrote:
It also touches upon a rebalance on access like mechanism where we could
potentially, move data out of existing bricks to a newer brick faster, in
the case of brick addition, and vice versa for brick removal, and heal
On 06/30/2014 02:00 AM, Xavier Hernandez wrote:
Hi Shyam,
On Thursday 26 June 2014 14:41:13 Shyamsundar Ranganathan wrote:
It also touches upon a rebalance on access like mechanism where we could
potentially, move data out of existing bricks to a newer brick faster, in
the case of brick
Besides bandwidth limits, there also needs to be monitors on brick latency.
We don't want so many queued iops that operating performance is impacted.
AFAIK - rebalance and self-heal threads run in low-priority queue in
io-threads by default.
--
Religious confuse piety with mere ritual, the
