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
On 07/01/2014 11:15 AM, Harshavardhana wrote:
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.
No,
On Monday 30 June 2014 16:18:09 Shyamsundar Ranganathan wrote:
Will this rebalance on access feature be enabled always or only during a
brick addition/removal to move files that do not go to the affected brick
while the main rebalance is populating or removing files from the brick ?
The
- Original Message -
From: Shyamsundar Ranganathan srang...@redhat.com
To: Xavier Hernandez xhernan...@datalab.es
Cc: gluster-devel@gluster.org
Sent: Tuesday, July 1, 2014 1:48:09 AM
Subject: Re: [Gluster-devel] Feature review: Improved rebalance performance
From: Xavier
- Original Message -
From: Xavier Hernandez xhernan...@datalab.es
To: Raghavendra Gowdappa rgowd...@redhat.com
Cc: Shyamsundar Ranganathan srang...@redhat.com, gluster-devel@gluster.org
Sent: Tuesday, July 1, 2014 3:10:29 PM
Subject: Re: [Gluster-devel] Feature review: Improved
On Tuesday 01 July 2014 05:55:51 Raghavendra Gowdappa wrote:
- Original Message -
Another thing to consider for future versions is to modify the current
DHT
to a consistent hashing and even the hash value (using gfid instead of
a
hash of the name would solve the rename
From: Xavier Hernandez xhernan...@datalab.es
On Monday 30 June 2014 16:18:09 Shyamsundar Ranganathan wrote:
Will this rebalance on access feature be enabled always or only during
a
brick addition/removal to move files that do not go to the affected brick
while the main rebalance is
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
10 matches
Mail list logo
