Re: [Gluster-devel] regarding spurious failure tests/bugs/bug-1112559.t
Hi All, Thanks Justin for the setup(slave30). Executed the whole regression suite on slave30 multiple times. Once there was a failure of ./tests/basic/mgmt_v3-locks.t with a core http://build.gluster.org/job/rackspace-regression-2GB-joe/12/console Test Summary Report --- ./tests/basic/mgmt_v3-locks.t (Wstat: 0 Tests: 14 Failed: 3) Failed tests: 11-13 Files=250, Tests=4897, 3968 wallclock secs ( 1.91 usr 1.41 sys + 330.06 cusr 457.27 csys = 790.65 CPU) Result: FAIL + RET=1 ++ ls -l /core.20215 ++ wc -l There is a glusterd crash Log files and core files are available @ http://build.gluster.org/job/rackspace-regression-2GB-joe/12/console And the very next regression test bug-1112559.t failed with the same port unavailability. http://build.gluster.org/job/rackspace-regression-2GB-joe/13/console After this I restart slave30 and executed the whole regression test again and never hit his issue. Looks like the issue is not originated @ bug-1112559.t. The failure in bug-1112559.t test 10 is the result because of a previous failure or crash. Regards, Joe - Original Message - From: Justin Clift jus...@gluster.org To: Vijay Bellur vbel...@redhat.com Cc: Avra Sengupta aseng...@redhat.com, Joseph Fernandes josfe...@redhat.com, Pranith Kumar Karampuri pkara...@redhat.com, Gluster Devel gluster-devel@gluster.org Sent: Thursday, July 10, 2014 8:26:49 PM Subject: Re: [Gluster-devel] regarding spurious failure tests/bugs/bug-1112559.t On 10/07/2014, at 12:44 PM, Vijay Bellur wrote: snip A lot of regression runs are failing because of this test unit. Given feature freeze is around the corner, shall we provide a +1 verified manually for those patchsets that fail this test? Went through and did this manually, as Gluster Build System. Also got Joe set up so he can debug things on a Rackspace VM to find out what's wrong. + 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] P
Raghavendra Gowdappa rgowd...@redhat.com wrote: I can help you out with the review of the paper. Here is it, please send a diff with your changes: http://ftp.espci.fr/shadow/manu/fuse.txt -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Proposal for change regarding latency calculation
Hello, Following is a proposal for modifying the io profiling capability of the io-stats xlator. I recently sent in a patch(review.gluster.org/#/c/8244/) regarding that, which uses the already written latency related functions in io-stats to dump info through meta and added some more data containers which would track some more fops related info each time a request goes through io-stats. Currently, before the io-stats' custom latency functions can run, the measure_latency and count_fop_hits option should be enabled. I propose to remove these two options entirely from io-stats. In order to track io performance, these options should be enabled all the time, or removed entirely, so that a record of io requests can be kept since mount time, else enabling these options only when it is required will not give you the average statistics over the whole period since the start. This is based on the methodology of Linux kernel itself, since it internally maintains the io statistics data structures all the time and presents it via /proc filesystem whenever required. Enabling of any option is not required, and the data available represents statistics since the boot time. I would like to know the views over this, if having io-stats profiling info available all the time would be a good thing? Apart from this, I was going over latency.c in libglusterfs, which does a fine job of maintaining latency info for every xlator and encountered an anomaly which I thought should be dealt with. The function gf_proc_dump_latency_info which dumps the latency array for the specified xlator consists of a last line which in the end flushes this array through memset after every dump. That means, you get different latency info every time you read the profile file in meta. I think, flushing the data structure after every dump is wrong since, you don't get overall stats since one enabled the option at the top of meta, and more importantly, multiple applications reading this file can get wrong info, since it gets cleared after one read only. If my reasons seem apt for you, I'll send a patch over for evaluation. Regards Vipul Nayyar ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Is this a transient failure?
On 14/07/2014, at 6:38 AM, Pranith Kumar Karampuri wrote: snip Kick off a regression test manually here, and see if the same failure occurs: http://build.gluster.org/job/rackspace-regression-2GB/ If it happens again, it's not a spurious one. I believe this is a spurious one. I didn't get a chance to debug this issue. Yeah, it ran through without any errors on the 2nd run. :) http://build.gluster.org/job/rackspace-regression-2GB/561/consoleFull + 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] regarding spurious failure tests/bugs/bug-1112559.t
On 14/07/2014, at 7:40 AM, Joseph Fernandes wrote: snip After this I restart slave30 and executed the whole regression test again and never hit his issue. Looks like the issue is not originated @ bug-1112559.t. The failure in bug-1112559.t test 10 is the result because of a previous failure or crash. Thanks Joe, that's excellent. Sounds like we're making progress. :) Git blame has Avra's name all over mgmt_v3-locks.t, so I guess Avra will take it from here. ; Avra, is that core file and the logs for it useful? It's easy to give you a login for slave30 too, so you can investigate at your leisure. (useful?) Regards and best wishes, Justin Clift -- 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
[Gluster-devel] Updating blog entry list on www.gluster.org?
Hi Eco, Humble just published a blog post about the new GlusterFS 3.4.5 beta2 RPMs: http://blog.gluster.org/2014/07/glusterfs-3-4-5beta2-rpms-are-available-now/ How do we get the www.gluster.org website updated, so new blog posts appear automagically? Regards and best wishes, Justin Clift -- 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] Patches to be merged before 3.6 branching
My patch for improving peer identification [1] needs to get in. It's functionally complete and can be merged right now. But KP has some minor comments. I'll update it tonight, and it should be good for merge by the morning, ~kaushal [1] https://review.gluster.org/8238 On Mon, Jul 14, 2014 at 7:33 PM, Vijay Bellur vbel...@redhat.com wrote: Hi All, I intend creating the 3.6 branch tomorrow. After that, the branch will be restricted to bug fixes only. If you have any major patches to be reviewed and merged for release-3.6, please update this thread. Thanks, Vijay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Patches to be merged before 3.6 branching
On 2014-07-14 16:03, Vijay Bellur wrote: Hi All, I intend creating the 3.6 branch tomorrow. After that, the branch will be restricted to bug fixes only. If you have any major patches to be reviewed and merged for release-3.6, please update this thread. Does this mean that https://bugzilla.redhat.com/show_bug.cgi?id=1113050 has no chance to get in (no patch for that yet, still trying to figure out how things work inside gluster)? I think http://review.gluster.org/8299 is important, since gluster will break with some locales. And I would really like to get http://review.gluster.org/8292, http://review.gluster.org/8208 and http://review.gluster.org/8203. All the things above should already be on https://bugzilla.redhat.com/show_bug.cgi?id=1117822, so maybe this mail is just noise. /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Is it OK to pick Code-Reviewer(s)
When submitting patches where there is an/some obvious person(s) to blame, is it OK/desirable to request them as Code-Reviewers in gerrit? /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Is it OK to pick Code-Reviewer(s)
When submitting patches where there is an/some obvious person(s) to blame, is it OK/desirable to request them as Code-Reviewers in gerrit? Inviting reviewers with clear interest or knowledge in a piece of code is not only OK but recommended. I think blame might not be a good idea, though. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Is it OK to pick Code-Reviewer(s)
On Mon, Jul 14, 2014 at 9:31 AM, Anders Blomdell anders.blomd...@control.lth.se wrote: When submitting patches where there is an/some obvious person(s) to blame, is it OK/desirable to request them as Code-Reviewers in gerrit? Gist of adding Core-Reviewers is to find faults in oneself - not the other way around :-) -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Patches to be merged before 3.6 branching
On 14/07/2014, at 4:20 PM, Anders Blomdell wrote: On 2014-07-14 16:03, Vijay Bellur wrote: Hi All, I intend creating the 3.6 branch tomorrow. After that, the branch will be restricted to bug fixes only. If you have any major patches to be reviewed and merged for release-3.6, please update this thread. Does this mean that https://bugzilla.redhat.com/show_bug.cgi?id=1113050 has no chance to get in (no patch for that yet, still trying to figure out how things work inside gluster)? Sounds like that would be a bug fix, so it'd get applied to everything that it makes sense too. eg likely 3.6, 3.5, 3.7dev, etc. I think http://review.gluster.org/8299 is important, since gluster will break with some locales. Also a bug fix. It seems simpler to commit sooner rather than later, but it'll depend on reviews. And I would really like to get http://review.gluster.org/8292, IPv6 support. Niels, have you had a change to look at this? Should we get this merged, and fix any bugs that turn up later? http://review.gluster.org/8208 Seems like a bugfix, so it can likely go in after Susant and others have finished working on it. and http://review.gluster.org/8203. Same as 8208, it looks like a bugfix. Seems further along the dev/review process. All the things above should already be on https://bugzilla.redhat.com/show_bug.cgi?id=1117822, so maybe this mail is just noise. Nah, reminders are useful. :) + 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] Change in glusterfs[master]: porting: use __builtin_ffsll() instead of ffsll()
CC gluster-devel, Anuradha who committed the test. Pranith On 07/15/2014 01:58 AM, Harshavardhana wrote: Mr Spurious is here again! Patch Set 2: Verified-1 http://build.gluster.org/job/rackspace-regression-2GB-triggered/351/consoleFull : FAILED Test Summary Report --- ./tests/bugs/bug-1038598.t (Wstat: 0 Tests: 28 Failed: 1) Failed test: 28 Files=262, Tests=7738, 5904 wallclock secs ( 4.09 usr 2.35 sys + 546.04 cusr 750.64 csys = 1303.12 CPU) Result: FAIL ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Paper about GlusterFS on NetBSD
Raghavendra Gowdappa rgowd...@redhat.com wrote: What is the time-line you want this to be reviewed within? I am busy this week. Is it ok if I can pick this up after this week? If it is very urgent I can try to allocate some time for it. Next week is fine, no problem. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Change DEFAULT_WORKDIR from hard-coded value
http://review.gluster.org/#/c/8246/
Two important things it achieves
- Break-way from '/var/lib/glusterd' hard-coded previously,
instead rely on 'configure' value from 'localstatedir'
- Provide 's/lib/db' as default working directory for gluster
management daemon for BSD and Darwin based installations
${localstatedir}/db was used for FreeBSD (In fact FreeNAS) - where
we are planning for a 3.6 release integration as an experimental
option perhaps to begin with.
Since ${localstatedir}/lib is non-existent on non-linux platforms,
it was decided as a natural choice.
Future changes in next set would be migrate all the 'tests/*' to
handle non '/var/{lib,db}' directories.
Need your reviews on the present patchset, please chime in - thank you!
--
Religious confuse piety with mere ritual, the virtuous confuse
regulation with outcomes
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
