Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2015-05-19

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:04 ppai joined #gluster-dev
00:43 ppai joined #gluster-dev
00:54 badone joined #gluster-dev
01:20 wushudoin joined #gluster-dev
02:16 kdhananjay joined #gluster-dev
03:11 hagarth joined #gluster-dev
03:15 rjoseph joined #gluster-dev
03:26 overclk joined #gluster-dev
03:29 kdhananjay joined #gluster-dev
03:31 pranithk joined #gluster-dev
03:32 sakshi joined #gluster-dev
03:47 itisravi joined #gluster-dev
03:53 shubhendu joined #gluster-dev
03:54 pranithk itisravi: I was reviewing http://review.gluster.com/10776, I have some doubts
03:56 itisravi pranithk: okay
03:56 pranithk itisravi: Instead of changing afr-read-txn.c why not change afr_readdir_wind? i.e. if afr_readdir_wind is called with subvol -1 and the local->op_errno is set to EIO then wind to first up subvol?
03:57 itisravi pranithk: we have to allow other fops that calls read_txn, otherwise those fops were also failing. For eg. we were not able to create any files inside the directory in entry split-brain.
03:58 pranithk itisravi: what fops?
03:58 itisravi touch dir/file was failing
03:58 rjoseph joined #gluster-dev
03:58 pranithk itisravi: I mean which fop? STAT?
03:59 itisravi because it calls afr_stat on dir first, which would fail
03:59 itisravi pranithk: yes
04:03 pranithk itisravi: why is it not failing in v1 because stat would fail even there?
04:03 itisravi pranithk: I need to check in v1..
04:08 pranithk itisravi: I think I got it. In v1 directory is never treated as in entry split-brain
04:08 itisravi pranithk: we are storing only data/mdata sbrain in inode context..
04:09 pranithk itisravi: yes
04:09 itisravi pranithk: and afr_is_split_brain checks only for that.
04:09 pranithk itisravi: in v2 stat is based on whether the file is in split-brain on DATA_TRANSACTION and since the directory is in entry split-brain even stat is failing
04:09 itisravi pranithk: yes
04:17 rajesh joined #gluster-dev
04:19 pranithk joined #gluster-dev
04:19 pranithk itisravi: sorry, there was a disconnect,
04:19 itisravi pranithk: no probs
04:19 nbalacha joined #gluster-dev
04:19 pranithk itisravi: this is what I typed... "(09:39:38 AM) pranithk: itisravi: in v2 stat is based on whether the file is in split-brain on DATA_TRANSACTION and since the directory is in entry split-brain even stat is failing
04:19 pranithk (09:41:19 AM) pranithk: itisravi: could you submit 10530 with bug-id
04:19 pranithk (09:43:30 AM) pranithk: itisravi: will merge it once the regression passes."
04:20 itisravi pranithk: already has the bug id in the commit message
04:20 hagarth pranithk: doing ok today?
04:20 itisravi pranithk: not sure why it shows rfc.
04:21 pranithk itisravi: interesting wondering why it shows as rfc :-)
04:21 pranithk itisravi: I will submit the patch
04:21 itisravi pranithk:  I submitted this along with 10667  which was an rfc patch. But I entered the ID  for this one.
04:21 itisravi pranithk: cool!
04:21 pranithk hagarth: thankfully no fever. Only cold and throat infection. Took medicines..
04:22 itisravi pranithk: you should avoid the ac then.
04:22 hagarth pranithk: good, hope you feel better soon!
04:22 pranithk itisravi: yeah... I want to come but don't want to infect others so won't come.
04:23 kanagaraj joined #gluster-dev
04:23 itisravi pranithk: hmm
04:25 pranithk itisravi: for allowing readdir on dirs with split-brain and creates etc...
04:26 pranithk itisravi: Simulate that the entries are readable even when the directory is in split-brain
04:28 itisravi pranithk: that is what the patch does no..?
04:28 itisravi pranithk: pretend that there is no entry split-brain for those fops.
04:30 pranithk itisravi: Yes, the intention of patch is correct.
04:31 atinmu joined #gluster-dev
04:32 pranithk itisravi: we can pretend that way by adding the following line at line:80
04:32 hagarth itisravi: should setfattr succeed when only the arbiter is online?
04:33 itisravi hagarth: No, quorum won't be met and we should not allow modification fops if only one brick (arbiter or not) is online.
04:33 pranithk itisravi: if (local->readable == 0 && local->transaction.type == AFR_DATA_TRANSACTION && inode->ia_type == IA_IFDIR) local->readable = maskof(local->child_up)
04:33 hagarth itisravi: arbiter.t seems to indicate that setfattr should succeed in such a case.. maybe that's the problem with the test?
04:34 itisravi hagarth: I see "TEST ! setfattr -n user.name -v value3 $M0/file"
04:35 hagarth itisravi: TEST setfattr -n user.name -v value3 $M0/file
04:35 hagarth
04:35 itisravi hagarth: umm.. I mean 'TEST !'  i.e the test must fail..
04:35 hagarth ah, rather arbiter is the only source for the test I pasted
04:36 itisravi hagarth: oh okay
04:36 hagarth but client quorum should be met
04:36 hagarth wonder why that test fails every now and then
04:36 ashishpandey joined #gluster-dev
04:38 pranithk itisravi: sorry line:85
04:38 itisravi pranithk: checking..
04:39 pranithk itisravi: [f]getxattr happens with read-txn on METADATA transaction, so it will work accordingly based on metadata is in split-brain or not.
04:41 ndarshan joined #gluster-dev
04:43 pranithk ashishpandey: morning! did you get a chance to see my mail about the bug triage?
04:43 itisravi pranithk: what is maskof(local->child_up)? Choose the first child that is up?
04:44 pranithk itisravi: no, if 'n'th child is up, 'n' th bit will be set
04:44 itisravi pranithk: oh but we need to set a value for read_subvol, not readable.
04:45 itisravi pranithk: shall I call you?
04:45 pranithk itisravi: basically local->readable should be same as child_up. Let the policy decide which one to choose
04:46 pranithk itisravi: forget about mask, working too much on ec :-). Everything is mask in that...
04:47 itisravi pranithk: okay
04:47 pranithk itisravi: you got the idea?
04:47 pranithk itisravi: if not, feel free to call me, I will explain
04:48 itisravi pranithk: Let me think. why don't you give a -1 on the patch with what you said
04:48 ashiq joined #gluster-dev
04:48 pranithk itisravi: feel free to add this bit on the patch and mark it -1. review.gluster.org is too slow...
04:48 pranithk itisravi: from home I mean
04:49 pranithk itisravi: wait it is fast now, I will add
04:49 itisravi pranithk: cool.
04:52 rafi joined #gluster-dev
04:59 deepakcs joined #gluster-dev
05:06 jiffin joined #gluster-dev
05:08 rafi joined #gluster-dev
05:09 anrao joined #gluster-dev
05:10 spandit joined #gluster-dev
05:10 Apeksha joined #gluster-dev
05:11 pppp joined #gluster-dev
05:17 schandra joined #gluster-dev
05:26 gem joined #gluster-dev
05:28 hchiramm_afk schandra, ping
05:28 glusterbot hchiramm_afk: Please don't naked ping. http://blogs.gnome.org/markmc/2014/02/20/naked-pings/
05:32 nkhare joined #gluster-dev
05:39 krishnan_p joined #gluster-dev
05:52 hgowtham joined #gluster-dev
06:06 Manikandan joined #gluster-dev
06:08 poornimag joined #gluster-dev
06:09 tigert morning
06:10 tigert hchiramm__: so any luck with the readthedocs build?
06:21 tigert hchiramm__: I am confused as to where does the title "Setup Bare metal" come from in the readthedocs navigation?
06:21 tigert - ['Install-Guide/Setup_Bare_metal.md', 'Install Guide', 'Setting up on physical servers']
06:21 tigert says the yml file
06:21 aravindavk joined #gluster-dev
06:22 tigert does it take it from the filename somehow even when you specify a title (and why does it make it a one-member "group" in the navigation?
06:27 schandra tigert, there has been small version mismatch. that is causing title/filename issue (setup bare metal)
06:28 schandra sorting the mismatch
06:29 hchiramm__ tigert, yes
06:30 hchiramm__ we are almost done..
06:30 hchiramm__ schandra, is working on the mismatch
06:30 tigert ok
06:31 Guest72040 joined #gluster-dev
06:33 poornimag joined #gluster-dev
06:40 tigert hchiramm__: http://docs.phinx.org/en/latest/ < this also uses readthedocs,
06:40 tigert see how they have the navigation sections collapsed by default
06:41 raghu joined #gluster-dev
06:41 tigert it would be much clearer to find stuff if we had just the main Install Guide / Admin Guide / Developer Guide and Features in the navigation bar
06:42 tigert and those expand when you open a guide
06:42 tigert looks like it can be done, but maybe some configuration is needed, I cannot seem to find documentation about that yml file format
06:43 Gaurav_ joined #gluster-dev
06:43 rgustafs joined #gluster-dev
06:48 hagarth tigert: morning
06:48 tigert morning :)
06:48 hagarth are we good to update gluster.org with a note about 3.7 being released?
06:49 tigert in a bit
06:49 hchiramm__ tigert, everything has been sorted out
06:50 hchiramm__ tigert, when r u pushing your new website ?
06:50 tigert I need to reach misc
06:51 tigert he is in Canada though, so we need to do the thing over email
06:51 tigert but lets do it so that I put up the 3.7 announcement on the current site (and to the new one also)
06:51 spalai joined #gluster-dev
06:51 tigert then we see what is missing on http://glusternew-tigert.rhcloud.com/ and add
06:51 tigert and then once we are happy we tell him to switch it over
06:51 kdhananjay joined #gluster-dev
06:51 tigert and then fix any remaining issues
06:52 hagarth tigert: sounds like a good plan
06:54 atalur joined #gluster-dev
06:55 poornimag joined #gluster-dev
07:07 anekkunt joined #gluster-dev
07:09 Guest72040 joined #gluster-dev
07:09 atinmu joined #gluster-dev
07:11 hchiramm__ tigert, the new PRs should point to this repo https://github.com/humblec/glusterdocs
07:11 tigert you have a new repo?
07:11 hchiramm__ clone of old ..
07:12 tigert we should eventually move it to the gluster organization in github
07:12 hchiramm__ but I changed the repo name and resolved the issues we had with readthedocs
07:12 tigert ok
07:12 hchiramm__ yes.. will be doing once we are done with 3 more commits
07:12 hchiramm__ including your commit on AWS
07:12 tigert ok
07:12 arao joined #gluster-dev
07:12 tigert so without dash
07:12 tigert gluster-docs -> glusterdocs
07:13 hchiramm__ yes
07:13 tigert so I will do it this way:
07:14 tigert I will add news/ to the old site
07:14 tigert and we can then have announcements there
07:14 tigert and the same url then will work on the new site
07:14 tigert so we dont announce something and break it right the next day when we switch over :)
07:16 tigert there is basic blogging support on the framework, so we can use it for release news and announcements that are more official than planet blog posts
07:16 tigert we can then add the feed it to the planet also
07:16 tigert I think this is how it worked in the old planet gluster setup?
07:22 spalai1 joined #gluster-dev
07:35 hchiramm__ poornimag++
07:35 glusterbot hchiramm__: poornimag's karma is now 1
07:41 tigert hchiramm__: fired up a git push for the 3.7 news
07:41 tigert lets see in a hour
07:41 hchiramm__ tigert++ , awesome!
07:41 glusterbot hchiramm__: tigert's karma is now 8
07:41 tigert if the world catches fire and the site burns down, or it might work :-)
07:41 hchiramm__ :)
07:43 arao joined #gluster-dev
07:44 hchiramm__ arao, ping
07:44 glusterbot hchiramm__: Please don't naked ping. http://blogs.gnome.org/markmc/2014/02/20/naked-pings/
07:44 atinmu joined #gluster-dev
07:44 sac joined #gluster-dev
07:46 hagarth tigert: awesome, thanks!
07:46 nishanth joined #gluster-dev
07:46 hchiramm__ tigert, can u merge hagarth's PR on download ?
07:47 hchiramm__ https://forge.gluster.org/gluster-site/gluster-site/merge_requests/7
07:53 ira joined #gluster-dev
08:00 tigert done
08:00 tigert lets wait for it to update
08:00 hchiramm__ sure. !
08:04 tigert should I point documentation nav link to readthedocs already on the old site?
08:05 hchiramm__ tigert, readthedocs have latest documentation
08:06 tigert I guess anything is better than the old stuff we have in gluster.org/documentation/
08:06 * tigert pushes
08:06 hchiramm__ so it shouldnt be an issue if you point current gluster.org to rtd
08:06 hchiramm__ indeed ..
08:06 tigert I am trying to prepare the new site to match the changes and make it ready for misc to switch over
08:07 tigert I guess I should make this the master branch too
08:07 hchiramm__ that would be awesome
08:07 tigert now that we are this far
08:27 Gaurav_ joined #gluster-dev
08:28 Joe_f joined #gluster-dev
08:29 pk1 joined #gluster-dev
08:31 pk1 xavih: ec_get_size_version is used also by stat and readv they are also using prepare_update_cbk which endup updating dirty[]. So I was kind of thinking get_size_version_set function should be used by stat and readv as xattrop_cbk instead of lookup_cbk, I will need to change somethings there, that is the reason I kept it.
08:39 anrao joined #gluster-dev
08:40 kdhananjay joined #gluster-dev
08:42 hagarth pk1: review and merge http://review.gluster.org/10813 ?
08:45 pk1 hagarth: done
08:49 pk1 xavih: posted the reasons on the patch as well. Let me know if this patch as is can be taken in and we can handle rename, readv/stat issues in separate patch. Please update on the patch comments itself.
08:50 pk1 xavih: I will be posting the locks change which can be used in ec for co-operative locking by EOD today.
08:51 xavih pk1: ec_get_size_version_set and ec_prepare_update_cbk are doing basically the same. The (almost) only difference is the argument list because they are different callbacks. If we are not using lookup anymore, the small differences could be added to ec_prepare_update_cbk (and maybe change the name)
08:51 xavih pk1: anyway I think it's ok to merge the patch as it is and solve the rename issue later
08:51 pk1 xavih: no, prepare_update_cbk also maintains dirty which version_set is not...
08:52 xavih pk1: yes, that's the difference we need to merge. Otherwise functions are equal...
08:52 pk1 xavih: dirty[] should be marked true only if we send xattrop with dirty set to '1' but that is not the case in get_size_version.
08:53 xavih pk1: I'm working on the change for co-operative locking on ec side, but I'm having some races that I'm trying to identify and solve...
08:54 tigert hagarth: around?
08:54 pk1 xavih: cool. If you resubmit your change for "Correctly cleanup delayed locks" I want to merge this patch and lookup patch so that we can remove ec spurious error tests
08:55 pk1 xavih: Did you get a chance to see my mail about problem with nfs server restarts and version update on gluster-devel?
08:55 xavih pk1: In a few minutes. I've just found a race while testing :P
08:55 pk1 xavih: :-) great
08:55 xavih pk1: yes, I've just read it
08:56 pk1 xavih: hey could you +2 lookup change so that I can merge it
08:56 xavih pk1: I think it's a very bad idea to stop a process with a KILL in normal circumstances, anyway I assume that this will be very difficult to solve
08:56 pk1 xavih: I also posted a way to recover from it...
08:57 pk1 xavih: yes it is difficult to solve
08:59 xavih pk1: +2 done
09:00 atinmu hagarth, I am hitting a crash when I start glusterd with release-3.5 branch
09:00 atinmu is anyone aware of it?
09:01 hagarth tigert: yes, now
09:01 hagarth pk1: thanks!
09:01 hagarth atinmu: does the backtrace point to something known?
09:02 atinmu hagarth, __gf_calloc crashed
09:03 xavih pk1: I'll think about the NFS issue. Detecting the problem is easy doing what you say, but healing it could involve additional logic based on try and error. Currently implementation is not really prepared to handle these cases
09:03 hagarth atinmu: possible memory corruption? what event in startup triggers the crash?
09:04 atinmu hagarth, its at the init when ctx is allocated
09:04 pk1 xavih: Yes, it is a long shot, but Just wanted to gather inputs...
09:04 tigert hagarth: should I merge the new site stuff to master?
09:05 atinmu hagarth, let me investigate on it
09:05 hagarth pk1: any possibility of doing a graceful nfs shutdown after all pending ec transactions are complete?
09:05 hagarth tigert: +1 to that
09:05 hagarth atinmu: ok
09:05 tigert hagarth: I feel bad for debloper, hopefully he wont stop helping us
09:06 * tigert is very much looking into his contributions on the community building stuff
09:06 tigert looking forward to, even
09:06 hagarth tigert: no, he should be able to help us. let us work collaboratively to incorporate his ideas as well.
09:07 xavih pk1: just updated http://review.gluster.org/10787
09:07 tigert yeah
09:07 tigert definitely
09:07 tigert now lunch
09:08 pk1 hagarth: graceful shutdown had some problem, that is why we resorted to SIGKILL
09:08 pk1 xavih: on it
09:08 hagarth pk1: no, we could still do SIGKILL to nfs but only after ec lets glusterd know that it is done?
09:09 hagarth pk1: I think SIGKILL was brought in to let re-tries from nfs clients happen and not have the client-server connection torn down gracefully.
09:10 pk1 hagarth: Oh you mean glusterd will need to tell nfs server that it is going to restart nfs server?
09:10 xavih hagarth, pk1: I think it would be better to do graceful shutdowns for all processes when possible (this is something that I would really try for version 4). Anyway we still need to handle these cases because they could happen even if processes are stopped correctly
09:10 hagarth pk1: maybe do a graceful shutdown of NFS but not perform close on sockets if they happen to be running for NFS?
09:11 hagarth pk1: yes, something like that .. the other alternative could be what  i referred above
09:11 hagarth xavih: right, unless we let translators terminate gracefully with no pending state updates we will run into this problem.
09:12 pk1 hagarth: Hmm.. something to think about. Will update you.
09:13 hagarth pk1: ok
09:13 ndevos pk1, hagarth: ah, but SIGKILL for NFS has problems too, it does not unregister itself at portmap/rpcbind that way - and I need to fix tat
09:13 ndevos *that
09:14 hagarth ndevos: wouldn't reuseaddr during bind take care of that? or is it something different?
09:15 ndevos hagarth: no, registering at rpcbind fails when rpcbind thinks something else is registered already
09:15 hagarth ndevos: hmm, then how does nfs restart work from glusterd now? since we anyway SIGKILL it?
09:16 aravindavk joined #gluster-dev
09:16 ndevos hagarth: maybe it works for the nfs protocol, but not for others, I'm not sure
09:17 schandra joined #gluster-dev
09:17 pk1 xavih: Gave +2, Will merge it after regression run. I will post a patch removing ec tests from bad tests once this is merged. I think all known EIO errors are solved after this fix :-)
09:17 ndevos hagarth: oh, maybe it is only a problem when stopping gluster/nfs and starting nfs-ganesha afterwards....
09:17 xavih pk1: I hope so :)
09:17 hagarth pk1: unless regression tests are unblocked from a patch, can we please refrain merging them?
09:18 pk1 hagarth: These patches solve the regression runs. Once xavih's patch is merged we solved all known Spurious EIO problems that we found. I merged/will merge the patches because they solve these problems
09:19 pk1 hagarth: Oh is the process to have removal of bad test also in the same patch?
09:19 hagarth pk1: if we are confident about problems being solved, let us update run-tests.sh
09:19 hagarth else it becomes a problem to determine practically if the patch has solved a problem..
09:20 hagarth wow .. too many problems in the sentence above. that itself seems like a problem :).
09:20 hagarth ndevos: might be interesting to determine why gNFS works but Ganesha portmap registration fails
09:22 pk1 xavih: I will be updating your patch with removal of badtests in ec from run-tests.sh
09:22 pk1 xavih: is that ok?
09:23 atinmu hagarth, I figured out the problem, some uncleaned libraries :)
09:23 atinmu hagarth, nothing to worry :)
09:23 hagarth atinmu: great :)
09:24 ndevos hagarth: yes, it is something I need to look at, bug 1183118 should track it
09:24 glusterbot Bug https://bugzilla.redhat.com:443/show_bug.cgi?id=1183118 medium, medium, ---, bugs, NEW , Gluster/NFS does not exit cleanly on reboot, leaving rpcbind registrations behind
09:26 ndevos that is only an issue on EL-7, and it will be fixed with an rpcbind update... I'm not sure yet how to handle it in gNFS
09:27 Manikandan joined #gluster-dev
09:27 * hagarth checks fini in nfs
09:28 hagarth ndevos: during a reboot, I would expect processes to get a SIGTERM.. so cleanup_and_exit() should get called.
09:29 ndevos hagarth: not with systemd, I think :)
09:29 hagarth ndevos: systemd-- ;)
09:29 glusterbot hagarth: systemd's karma is now -1
09:29 hagarth how does it terminate a process during shutdown?
09:30 hagarth spandit: are you looking into the quota regression failures? if yes, can you please update the etherpad?
09:31 ndevos hagarth: it depends... there is no gluster-nfs.service that handles it, so glusterd gets stopped nicely, I think other processes just die on poweroff/reboot
09:31 spandit hagarth : currently I am not, I will update that once I start looking into it
09:32 hagarth spandit: ok
09:32 xavih pk1: sure, no problem
09:33 xavih pk1: In this case maybe it will be better to run multiple regression tests to be sure that there are no spurious failures
09:45 ndevos does anyone know if this regression test hang has been reported before? http://build.gluster.org/job/rackspace-regression-2GB-triggered/9241/console
09:46 hagarth ndevos: nbalacha is aware of this one I think
09:47 nbalacha hagarth, ndevos oh yes
09:47 nbalacha I will post a patch to fix the hang, if not the underlying issue
09:47 hagarth nbalacha: ok, great!
09:47 Manikandan joined #gluster-dev
09:47 nbalacha ndevos, can this regression run be killed?
09:48 nbalacha ndevos, or else it is gonna take hours to complete
09:51 ndevos nbalacha: yes, we can kill it
09:51 ndevos nbalacha: in the upper right corner, there is a red  [x] , feel free to click it
09:52 ndevos I think we can also set a timeout for jenkins jobs, 4 hours for the regression should do
09:52 * ndevos looks for the option and will enable it
09:52 nbalacha ndevos, thanks
09:55 ashiq joined #gluster-dev
09:58 ndevos hagarth: could I install+enable https://wiki.jenkins-ci.org/display/JENKINS/Build-timeout+Plugin in our Jenkins?
09:58 hagarth ndevos: go ahead!
09:58 ndevos hagarth: ok!
10:02 ashiq joined #gluster-dev
10:10 ira joined #gluster-dev
10:11 ira joined #gluster-dev
10:21 hagarth tigert: the changes don't seem to be live as yet?
10:21 tigert no
10:21 tigert investigating as why
10:22 hagarth tigert: ok
10:35 rgustafs joined #gluster-dev
10:42 ndevos ping atinmu: will you host the bug triage meeting again?
10:46 kkeithley1 joined #gluster-dev
10:46 ashiq joined #gluster-dev
11:20 ndevos ping atinmu, rafi: will one of you host the bug triage meeting?
11:22 rafi ndevos: I will be attending a meeting , I'm not sure whether I can join or not
11:25 atinmu ndevos, hi
11:25 atinmu ndevos, I was away
11:26 atinmu ndevos, if possible could you host it? I might have to leave a bit early due to some personal commitments, just got a call few minutes back
11:26 atinmu ndevos, otherwise I was planning to host it
11:31 ndevos atinmu, rafi: okay, I can host it, that should work
11:31 atinmu ndevos, sorry for the late notice, next week is definitely mine :)
11:32 ndevos atinmu: np!
11:37 gem hagarth, ping, can you see these patches and merge them? http://review.gluster.org/#/c/9967/ http://review.gluster.org/#/c/9565/
11:37 hagarth gem: not merging any patches unless they fix a regression problem
11:38 gem hagarth, okay. didn't know that. thanks!
11:40 ndevos REMINDER: the weekly Gluster Bug Triage starts in ~20 minutes in #gluster-meeting
11:47 schandra gem, Manikandan thanks!!
11:47 schandra gem++
11:47 glusterbot schandra: gem's karma is now 9
11:47 schandra Manikandan++
11:47 glusterbot schandra: Manikandan's karma is now 4
11:47 gem schandra, :)
11:47 Manikandan schandra, welcome:)
12:01 rafi1 joined #gluster-dev
12:01 ndevos REMINDER: the weekly Gluster Bug Triage starts now minutes in #gluster-meeting
12:09 tigert hagarth: I need to reach to misc to debug the site, and I think he is asleep now :P
12:09 tigert something is not building
12:10 tigert darn it
12:17 rafi joined #gluster-dev
12:18 spalai1 left #gluster-dev
12:26 ira_ joined #gluster-dev
12:29 dlambrig joined #gluster-dev
12:30 rgustafs joined #gluster-dev
12:33 atalur joined #gluster-dev
12:42 shaunm_ joined #gluster-dev
12:42 shyam joined #gluster-dev
12:46 shubhendu joined #gluster-dev
12:48 arao joined #gluster-dev
12:52 pranithk joined #gluster-dev
12:53 pranithk xavih: I think for co-operative locking, it is good enough if we get the lock counts in heavy hitter fops like writev, readv, create, mknod, unlink. What do you say?
13:03 hagarth tigert: ok, is he in vancouver atm?
13:03 shubhendu joined #gluster-dev
13:04 ndevos rafi++ RaSTar++ kkeithley++
13:04 glusterbot ndevos: rafi's karma is now 12
13:04 glusterbot ndevos: RaSTar's karma is now 5
13:04 glusterbot ndevos: kkeithley's karma is now 67
13:07 hagarth ndevos++
13:07 glusterbot hagarth: ndevos's karma is now 125
13:10 vikumar joined #gluster-dev
13:12 pppp joined #gluster-dev
13:14 xavih pranithk: true, but the problem is not on the particular fop, it's in the logic to manage the locks themselves
13:15 xavih pranithk: I'll try to fix all races I've found today or tomorrow
13:25 rgustafs joined #gluster-dev
13:27 pranithk xavih: But without support from locks xlator how can we do it?
13:27 shyam left #gluster-dev
13:27 pranithk xavih: We still need to query locks xlator for number of locks, right?
13:28 xavih pranithk: Oh, I thought you were talking about the ec side...
13:28 pranithk xavih: yeah :-). So you already started implementing co-operative locking in ec?
13:28 xavih pranithk: yes, but I'm seeing some races that I need to solve
13:29 xavih pranithk: in theory the change is already done, but it doesn't work yet :(
13:29 pranithk xavih: How can we test it without locks change?
13:30 xavih pranithk: I'm simulating forced unlocks :)
13:31 pranithk xavih: Oh you are assuming that in write/read it tells that there are more locks?
13:31 badone_ joined #gluster-dev
13:31 xavih pranithk: yes
13:31 pranithk xavih: ah! cool
13:31 shyam joined #gluster-dev
13:35 arao joined #gluster-dev
13:40 rafi RaSTar++ ndevos++ kkeithley++ thanks for the bug triage meeting
13:40 glusterbot rafi: RaSTar's karma is now 6
13:40 glusterbot rafi: ndevos's karma is now 126
13:40 glusterbot rafi: kkeithley's karma is now 68
13:47 wushudoin joined #gluster-dev
13:55 hagarth tigert: any ETA from misc on this issue?
13:56 itisravi joined #gluster-dev
14:06 nkhare joined #gluster-dev
14:17 anoopcs anoop
14:20 kdhananjay joined #gluster-dev
14:45 aravindavk joined #gluster-dev
14:46 pranithk joined #gluster-dev
14:50 badone_ joined #gluster-dev
14:58 itisravi joined #gluster-dev
15:01 kanagaraj joined #gluster-dev
15:20 badone_ joined #gluster-dev
15:25 itisravi hagarth: ping. would you happen to know how I can get the core file in http://build.gluster.org/job/rackspace-regression-2GB-triggered/8723/consoleFull
15:25 itisravi I only see the log files being archived, not the core.
15:26 hagarth itisravi: no core was probably seen during the run
15:26 hagarth itisravi: ENOTCONN could be coming from client-quorum?
15:26 itisravi hagarth: yes
15:26 hagarth it is only test 38 that has failed
15:27 itisravi hagarth: yes there is a core.5441 listed though
15:27 hagarth itisravi: probably from a previous regression run
15:27 itisravi hagarth: oh okay
15:27 hagarth itisravi: we take a core count before and after the test run
15:28 itisravi hagarth: okay
15:28 hagarth if there's a positive difference in the count, only then it is regarded as a dump that happened in the interval of the run and is archived
15:28 ndevos hchiramm__: have you already started a package review to get python-libgfapi into Fedora?
15:28 itisravi hagarth: got it.
15:28 ndevos or hchiramm ^ :)
15:29 hagarth ndevos: I always have that confusion too ;)
15:29 * itisravi arbiter.t is running succesfully 24th time in my machine
15:29 hagarth itisravi: arbiter.t is one which fails easily on my machine
15:29 ndevos itisravi: did you run ./configure with --enable-debug?
15:30 itisravi hagarth: which test does it fail?
15:30 itisravi ndevos: yes.
15:30 hagarth ndevos: would we have to package python-libgfapi + java-libgfapi in f23 now?
15:30 hagarth itisravi: 28
15:30 * hagarth tests again
15:30 itisravi hagarth: okay
15:30 ndevos hagarth: "have to" maybe not, but that would be nice to increase adoption, right?
15:30 itisravi hagarth: unrealted but you wanted to merge http://review.gluster.org/#/c/10253/.
15:30 hagarth ndevos: as in, if we want to .. it would have to be F23 right?
15:31 hagarth itisravi: failed again
15:31 itisravi 28?
15:31 hagarth itisravi: are you ok with 10253?
15:31 hagarth itisravi: yes
15:31 itisravi hagarth: okay
15:31 itisravi hagarth: yes I gave a  +1
15:31 ndevos hagarth: I would like to see those packages in Fedora. they can get introduced in earlier versions too, if we would like that
15:31 hagarth itisravi: ok
15:32 hagarth ndevos: that would be cool. I am planning to upgrade to F22 soon .. would be nice to have those packages in there :)
15:32 ndevos hagarth: I'm also waiting for F22 to get out of Beta :)
15:33 hagarth ndevos: yeah, quite eager to adopt it soon :)
15:33 hagarth itisravi: different failures in this run
15:34 hagarth hmm test 31 in arbiter.t sometimes takes a while
15:35 itisravi hagarth: 31 is volume heal
15:35 hagarth and so does 33
15:36 itisravi hagarth:  :/ Are you running it on f21?
15:38 hagarth itisravi: Failed tests:  7, 14-16, 18, 21, 26-27, 32-33
15:38 hagarth itisravi: yes
15:49 hagarth itisravi: + eval setfattr -n user.name -v value3 /mnt/glusterfs/0/file
15:49 hagarth ++ setfattr -n user.name -v value3 /mnt/glusterfs/0/file
15:49 hagarth setfattr: /mnt/glusterfs/0/file: Read-only file system
15:50 kanagaraj joined #gluster-dev
15:50 hagarth itisravi: looks like client-quorum causes the setfattr in test 28 to fail
15:52 itisravi hagarth: yeah, but only one brick is down
15:54 hagarth itisravi: can it be possible that child_up also has only one brick online?
15:54 hagarth itisravi: let me check the logs
15:55 hagarth itisravi: check this out
15:55 hagarth [2015-05-19 15:49:20.412837] W [fuse-bridge.c:1263:fuse_err_cbk] 0-glusterfs-fuse: 73: SETXATTR() /file => -1 (Read-only file system)
15:55 hagarth [2015-05-19 15:49:21.039885] I [MSGID: 108002] [afr-common.c:3959:afr_notify] 0-patchy-replicate-0: Client-quorum is met
15:56 itisravi hagarth: thats strange.
15:56 hagarth so looks like there was a delay in getting CHILD_UP notification and setfattr went through before that ?
15:56 itisravi hagarth: yes
15:57 hagarth hmm, what does this expect -> EXPECT_WITHIN $PROCESS_UP_TIMEOUT "1" afr_child_up_status $V0 0
15:58 hagarth do we have a bug there?
15:59 itisravi hagarth: from volume.rc, it seems to get the staedump and check the brick status
16:05 hagarth itisravi: there seems to be a problem .. child_up[0..2] are set to 1
16:05 hagarth in statedump
16:06 poornimag joined #gluster-dev
16:07 hagarth itisravi: with a minor tweak to grep in volume.rc, it seems to be working now :)
16:07 itisravi hagarth: cool!
16:08 hagarth but still I can't fathom why all child_up[0..2] are being set to 1
16:08 itisravi hagarth: 0..2 meaning 0,1 and 2?
16:08 hagarth itisravi: yes
16:10 shyam joined #gluster-dev
16:11 itisravi hagarth: we are doing  a volume start force at line 37, so all children will be up right?
16:11 hagarth itisravi: so statedumps are happening so fast that they are getting overwritten?
16:12 hagarth meaning with the same timestamp in the name?
16:12 itisravi hagarth: not sure I follow...why is child_up[0..2]  being set to 1 incorrect?
16:15 hagarth itisravi: right, we see child_up soon after volume start force
16:16 hagarth itisravi: this got arbiter.t to work fine in my setup - http://paste.fedoraproject.org/223427/52142143/raw/
16:16 hagarth itisravi: bbiab, dinner
16:16 itisravi hagarth: okay
16:22 pranithk joined #gluster-dev
16:26 badone_ joined #gluster-dev
16:32 itisravi hagarth: Don't see how a -a flag to grep changes things. The existing syntax workfs for me.
16:33 shyam joined #gluster-dev
16:37 hagarth itisravi: http://lists.gnu.org/archive/html/bug-grep/2015-05/msg00002.html
16:40 itisravi hagarth: wow.
16:40 itisravi But I'm also running F21 with grep version 2.21
16:46 itisravi hagarth: Finally got an error " Launching heal operation to perform index self heal on volume patchy has been unsuccessful"
16:47 itisravi hagarth:  After "48 EXPECT_WITHIN $PROCESS_UP_TIMEOUT "Y" glustershd_up_status " , we also need to add the following:
16:48 itisravi_ joined #gluster-dev
16:49 itisravi_ hagarth: power cut in my home :(
16:49 itisravi_ We need to add:  EXPECT_WITHIN $CHILD_UP_TIMEOUT "1" afr_child_up_status_in_shd $V0 0
16:49 itisravi_ EXPECT_WITHIN $CHILD_UP_TIMEOUT "1" afr_child_up_status_in_shd $V0 1
16:52 * itisravi_ is logging off now. Will try to spend some more time and see if there are more checks to be added in arbiter.t
16:58 itisravi_ joined #gluster-dev
17:10 badone_ joined #gluster-dev
17:12 dlambrig joined #gluster-dev
17:27 shyam left #gluster-dev
17:27 shyam joined #gluster-dev
17:32 jiffin joined #gluster-dev
17:33 Guest63236 joined #gluster-dev
17:46 hagarth tigert: looks like the website has been update, thanks for that!
17:47 hagarth s/update/updated/
17:51 nbalacha joined #gluster-dev
17:56 dlambrig joined #gluster-dev
18:04 rafi joined #gluster-dev
18:04 Gaurav_ joined #gluster-dev
18:14 dlambrig joined #gluster-dev
18:20 ppai joined #gluster-dev
18:21 shaunm_ joined #gluster-dev
18:40 badone_ joined #gluster-dev
18:55 jiffin joined #gluster-dev
18:57 JoeJulian This looks ugly from 3.7.0:
18:57 JoeJulian <gluster-user> I do see something in the log "[2015-05-19 18:49:09.999332] E [glusterd-syncop.c:562:_gd_syncop_mgmt_lock_cbk] 0-management: Could not find peer with ID 12000000-0000-0000-5008-218c7f7f0000", but I have no idea where it's getting the 12000000-0000-0000-5008-218c7f7f0000 from
18:57 JoeJulian [11:55] <JoeJulian> Looks ugly to me. Too many 0s.
18:57 JoeJulian [11:55] <gluster-user> yeah, and none of my nodes have that ID
19:02 ndevos JoeJulian: I guess that is an incorrect offset in a structure, or a memory corruption or something, a lot of coredumps I look at have addresses like 0x7f7f.. in them
19:03 * ndevos goes afk again...
19:12 JoeJulian ndevos: I was thinking the same thing.
19:29 pranithk xavih: I wrote the change in locks xlator to go along with your ec patch. Will need to test it tomorrow. But seems like one more EIO issue may take precedence over it. I sent you a mail about it. I think we are inspecting things without taking appropriate locks in unlink/rename. I will work a bit more on that tomorrow morning and post any updates I may have on that.
19:37 ira_ joined #gluster-dev
19:38 * kkeithley_ curses git and debian packaging
20:33 dlambrig joined #gluster-dev
20:38 vimal joined #gluster-dev
21:00 pranithk left #gluster-dev
21:44 ppai joined #gluster-dev

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary