Re: [Gluster-devel] Feature review: Improved rebalance performance
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@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] syncops and thread specific memory regions
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. Optimization prevents recalculating address of variable mentioned in 1 every time its accessed, instead using an address calculated earlier. The bug fixed by [1] involved errno as the variable. However there are other pointers which are stored in TLS like, 1. The xlator object in whose context the current code is executing in (aka THIS, set/read by using __glusterfs_this_location() ). 2. A buffer used to parse binary uuids into strings (used by uuid_utoa () ). I think we can hit the corruption uncovered by [1] in the above two scenarios too. Comments? [1] http://review.gluster.org/6475 regards, Raghavendra. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] syncops and thread specific memory regions
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 single (code) control flow is executed in more than one thread. 3. Optimization prevents recalculating address of variable mentioned in 1 every time its accessed, instead using an address calculated earlier. The bug fixed by [1] involved errno as the variable. However there are other pointers which are stored in TLS like, 1. The xlator object in whose context the current code is executing in (aka THIS, set/read by using __glusterfs_this_location() ). 2. A buffer used to parse binary uuids into strings (used by uuid_utoa () ). I think we can hit the corruption uncovered by [1] in the above two scenarios too. Comments? I did discuss these same two problems with Pranith some time ago [1]. Basically the errno issue was caused because __errno_location() is declared with 'const': extern int *__errno_location (void) __THROW __attribute__ ((__const__)); # define errno (*__errno_location ()) __gluster_this_location() is not declared as 'const', so the compiler doesn't optimize it so much as __errno_location() and this bug is not present. The uuid_utoa() issue is not a problem as long as it is only used for logging purposes or very local access. The returned pointer cannot be stored anywhere for future access. At the time of that discussion, all these conditions were satisfied. Refer to the emails [1] for more detailed information. Xavi [1] http://gluster.org/pipermail/gluster-devel/2013-December/026279.html ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Reviewing patches early
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 leverage our smoke tests, thoughts? 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. + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Reviewing patches early
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 importantant conditions - Tabs - Whitespace - Unnecessary spaces ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Feature review: Improved rebalance performance
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, they don't. We tried doing that but based on experiences from users we disabled that in io-threads. Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
