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
Hi all,
The bug fixed by [1] is a one instance of the class of problems where:
1. we access a variable which is stored in thread-specific area and hence can
be stored in different memory regions across different threads.
2. A single (code) control flow is executed in more than one thread.
3.
On Wednesday 02 July 2014 07:57:52 Raghavendra Gowdappa wrote:
Hi all,
The bug fixed by [1] is a one instance of the class of problems where:
1. we access a variable which is stored in thread-specific area and hence
can be stored in different memory regions across different threads. 2. A
On 26/06/2014, at 7:27 PM, Harshavardhana wrote:
http://review.gluster.org/#/c/8181/ - posted a new change, wouldn't it
be worth to add this in smoke tests? rather than at ./rfc.sh ? - we
can provide a detailed summary - since we do not have 'commit/push'
style patch submission.
We can
Yeah, lets try this out. We can add the checkpatch.pl script to the
patch acceptance tests, and have an automatically triggered job that
runs it on patch submission. Should be pretty straightforward.
Let me work on the checkpatch script more to clean it up and make it
report properly for
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,
