- Original Message -
> From: "Xavier Hernandez"
> To: "Raghavendra Gowdappa"
> Cc: gluster-devel@gluster.org
> Sent: Wednesday, July 2, 2014 6:50:51 PM
> Subject: Re: [Gluster-devel] syncops and thread specific memory regions
>
> On Wednesday 02 July 2014 07:57:52 Raghavendra Gowdappa
On 07/02/2014 05:27 PM, 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 single (code) co
On 07/01/2014 04:52 PM, Xavier Hernandez wrote:
Hi,
current implementation of ec xlator uses inodelk/entrylk before each operation
to guarantee exclusive access to the inode. This implementation blocks any
other request to the same inode/entry until the previous operation has
completed and unlo
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, th
> 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
i
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
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
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. Opti
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 r
