Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2014-07-01

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

All times shown according to UTC.

Time Nick Message
00:40 bala joined #gluster-dev
01:05 hagarth joined #gluster-dev
01:36 bala joined #gluster-dev
03:25 kdhananjay joined #gluster-dev
03:36 MacWinner joined #gluster-dev
03:38 itisravi joined #gluster-dev
03:59 ndarshan joined #gluster-dev
04:02 bharata-rao joined #gluster-dev
04:14 shubhendu_ joined #gluster-dev
04:22 MacWinner joined #gluster-dev
04:22 kdhananjay joined #gluster-dev
04:22 semiosis joined #gluster-dev
04:22 lpabon joined #gluster-dev
04:22 xavih joined #gluster-dev
04:22 kkeithley joined #gluster-dev
04:22 sac`away` joined #gluster-dev
04:22 johnmark joined #gluster-dev
04:22 portante joined #gluster-dev
04:30 lalatenduM joined #gluster-dev
04:31 nishanth joined #gluster-dev
04:32 semiosis joined #gluster-dev
04:32 semiosis joined #gluster-dev
04:43 vimal joined #gluster-dev
04:44 skoduri joined #gluster-dev
04:57 spandit joined #gluster-dev
05:01 skoduri joined #gluster-dev
05:05 ppai joined #gluster-dev
05:07 kdhananjay joined #gluster-dev
05:32 kshlm joined #gluster-dev
05:34 vpshastry joined #gluster-dev
05:35 bala1 joined #gluster-dev
06:11 ppai joined #gluster-dev
06:12 skoduri joined #gluster-dev
06:36 kdhananjay joined #gluster-dev
06:43 kasturi joined #gluster-dev
06:48 krishnan_p joined #gluster-dev
07:05 itisravi_ joined #gluster-dev
07:21 vpshastry joined #gluster-dev
07:31 vpshastry joined #gluster-dev
07:58 ppai joined #gluster-dev
08:06 kanagaraj joined #gluster-dev
08:41 kanagaraj_ joined #gluster-dev
08:43 [o__o] joined #gluster-dev
08:48 [o__o] joined #gluster-dev
08:52 [o__o] joined #gluster-dev
09:06 vpshastry joined #gluster-dev
09:08 vpshastry joined #gluster-dev
09:14 ppai joined #gluster-dev
09:18 krishnan_p xavih, there?
09:19 xavih hi krishnan_p
09:19 krishnan_p xavih, I wanted to ask you a quick question on ec_combine.
09:19 krishnan_p xavih, hi
09:19 xavih tell me
09:20 krishnan_p xavih, what are you doing to the cbk(s) when ec_combine_check passes (ie. true)?
09:22 xavih krishnan_p: I group all answers that have compatible answer values in a group. The "head" of this group is the last answer received, and the remaining compatible answers are stored in cbk->next
09:22 xavih krishnan_p: is that what you are asking ?
09:23 xavih krishnan_p: ah, another thing... I keep the list of groups (fop->cbk_list) sorted by the number of answers in each group
09:23 xavih krishnan_p: this order is maintained by the while loop after ec_combine_check()
09:23 krishnan_p xavih, ah, i thought so too!
09:24 xavih krishnan_p: this way, the first in the list always contains the best answer candidate
09:24 krishnan_p xavih, thanks. Makes REPORT_ANSWER easy. Makes sense.
09:24 xavih krishnan_p: yw :)
09:25 krishnan_p xavih, Another thing that I noticed is that you are not using the list_for_each_entry_safe macro when you are deleting an item from the list in ec_combine
09:34 xavih krishnan_p: sorry, I was away...
09:35 xavih krishnan_p: yes, I'm not using the "safe" version because when I manipulate list elements inside the loop, is just before a break
09:35 xavih krishnan_p: so it won't have any problems
09:36 krishnan_p xavih, hmm OK
09:37 xavih krishnan_p: I can use the "safe" version if you think it would be better though
09:37 krishnan_p xavih, No. I didn't notice that you were breaking out the loop after you perform the 'unsafe' manipulation
09:42 krishnan_p xavih, I am still getting my way around the code. Once I am confident of my understanding, I will suggest meaningful recommendations :)
09:42 xavih krishnan_p: thanks :)
09:43 xavih krishnan_p: if there's anything else, don't hesitate to ask :)
09:46 krishnan_p xavih, I won't :) Would you be around for some more time? I have a few more questions popping in my head as I navigate the code.
09:46 xavih krishnan_p: sure. I'll be here some more hours (except a break for lunch :P)
09:48 krishnan_p xavih, what is the idea behind removing 'ans' from the fop->cbk_list and adding it to the tail of 'cbk' if its 'combinable?
09:49 [o__o] joined #gluster-dev
09:50 krishnan_p xavih, am i right in understanding that by the time FOP is  in PREPARE_ANSWER state, we should have fop->cbk_list with one entry per group, with each cbk having its own list of similar answers?
09:50 xavih krishnan_p: fop->cbk_list contains groups of answers only. If one of the groups is found to be combinable with the new answer, that group is removed because the new answer will represent that group
09:50 [o__o] joined #gluster-dev
09:51 xavih krishnan_p: yes, this condition is maintained all the time
09:51 krishnan_p xavih, Great! I am getting the hang of it I think :)
09:51 xavih krishnan_p: fop->cbk_list won't contain two combinable groups
09:51 xavih krishnan_p: there is an assumption here
09:52 xavih krishnan_p: if answer A is not combinable with answer C, and answer B is not combinable with answer C, then it is assumed that B and C are also not combinable
09:52 xavih krishnan_p: if this is not true, I'll have a problem, but I think it's a valid assumption
09:54 krishnan_p xavih, yeah. and you should not have a problem here since Integer '=' relationj in integer space is known to be transitive :)
09:55 krishnan_p combinable relation is transitive if and only if '=' is a transitive relation.
09:55 xavih krishnan_p: yes, but I was thinking more on things like some kind of answers could be considered equivalent even if they are not exactly the same
09:56 krishnan_p xavih, that can still be handled by setting a canonical value in the respective FOP's callback
09:56 xavih yes, that would be a good solution :)
09:56 krishnan_p xavih, this way ec_combine is agnostic to such details
09:57 xavih krishnan_p: yes, this would be the best solution. However I think it's not needed by now...
09:58 krishnan_p xavih, i have one request. Could you add a short description, one line, for interesting/important members of ec_* data structures
09:59 krishnan_p xavih, for instance, its not obvious what is the purpose of answer_list and list for ec_cbk_data_t.
09:59 xavih krishnan_p: ok, I will :)
09:59 krishnan_p xavih, yep. I can't imagine of such a case were we have non-equal yet equivalent errors
09:59 krishnan_p xavih, thanks!
10:00 xavih krishnan_p: in case of errors, it could happen, depending on what we prefer to do...
10:01 xavih krishnan_p: for example, when you remove a file, you can get ENOTENT from some bricks and ENOTDIR from others
10:01 krishnan_p xavih, by that I meant, I cant imagine of a specific case at this point in time. I didn't mean that in general it is unlikely to come up with such a case
10:01 xavih krishnan_p: this could be considered as ok and be merged. But I'm not doing this now.
10:02 krishnan_p xavih, OK. That is interesting.
10:03 krishnan_p xavih, In this review, I am focusing on the plumbings of the erasure code implementation like the state machine, combining of similar answers (not whether it makes sense) and less on the side of file system correctness.
10:03 xavih krishnan_p: if this happens, it means that something else must be broken and self-heal should take care of it, however in this case the current operation could fail with the current implementation
10:04 xavih krishnan_p: ok
10:04 xavih krishnan_p: I have some error "coalescing" ideas for future versions...
10:04 krishnan_p xavih, nice. Along the lines you were just talking or something different?
10:05 xavih krishnan_p: what do you mean ?
10:05 krishnan_p xavih, I wanted to know if your ideas on error coalescing is along the lines of identifying similar yet non-equal errors or something else.
10:07 xavih krishnan_p: it's basically meant to identify equivalent errors. It could be extended to other equivalences, but I haven't identified any other till now
10:08 krishnan_p xavih, OK. Waiting for you to be put your idea on gluster-devel mailing list soon :)
10:08 xavih krishnan_p: do you think it's the right time ?
10:09 krishnan_p xavih, are you targeting that for 3.6? what do you mean by right time?
10:09 lalatenduM joined #gluster-dev
10:09 xavih krishnan_p: I mean that I think this is not a must for ec. Not sure if it's the right moment to add it...
10:10 krishnan_p xavih, yeah. You should do it as a different feature on ec, without blocking this patch from getting merged.
10:11 xavih krishnan_p: ok, I'll write a mail :)
10:11 krishnan_p xavih, for throwing your idea for discussion, its best done right now :)
10:11 xavih krishnan_p: I'm also working on something similar to eager-locking in AFR. Should I also write an email about it ?
10:12 krishnan_p xavih, that one is also for ec?
10:12 xavih krishnan_p: yes. To improve its performance
10:12 krishnan_p xavih, my advice would be to drop a mail at all times. AFR developers would be able to share their stories of implementing and maintaining those optimisations for soem time now.
10:13 xavih krishnan_p: ok. I'll do that
10:13 krishnan_p xavih, they may be able to help you to avoid some mistakes that they might have failed to notice early on etc
10:13 krishnan_p xavih, great!
10:19 kkeithley1 joined #gluster-dev
10:44 ppai joined #gluster-dev
11:22 ppai joined #gluster-dev
11:24 ndk joined #gluster-dev
11:51 lalatenduM joined #gluster-dev
12:07 vikumar joined #gluster-dev
12:08 itisravi joined #gluster-dev
12:09 vpshastry1 joined #gluster-dev
12:09 sac`away joined #gluster-dev
12:09 vikumar joined #gluster-dev
12:09 itisravi joined #gluster-dev
12:09 vpshastry1 joined #gluster-dev
12:09 sac`away joined #gluster-dev
12:09 spandit_ joined #gluster-dev
12:09 darshan joined #gluster-dev
12:09 shubhendu__ joined #gluster-dev
12:10 vpshastry joined #gluster-dev
12:10 sac`away` joined #gluster-dev
12:10 kdhananjay joined #gluster-dev
12:10 lalatenduM_ joined #gluster-dev
12:10 itisravi_ joined #gluster-dev
12:10 spandit__ joined #gluster-dev
12:10 kasturi_ joined #gluster-dev
12:10 skoduri joined #gluster-dev
12:10 kshlm joined #gluster-dev
12:10 vikumar__ joined #gluster-dev
12:10 hchiramm__ joined #gluster-dev
12:11 ndarshan joined #gluster-dev
12:11 shubhendu joined #gluster-dev
12:25 edward1 joined #gluster-dev
12:25 edward1 joined #gluster-dev
12:26 bala1 joined #gluster-dev
12:47 lalatenduM_ ndevos, regarding 1100204, I have got a mail form Jose Castilo. have replied him with my patch
12:47 lalatenduM_ and also copied u in the mail
13:00 awheeler joined #gluster-dev
13:02 shyam joined #gluster-dev
13:07 kanagaraj joined #gluster-dev
13:20 kanagaraj joined #gluster-dev
13:25 tdasilva joined #gluster-dev
13:34 ndevos lalatenduM_: yeah, thats fine, I told him to contact you so that you dont duplicate the work
13:34 ndevos lalatenduM_: just left some notes in the review too
13:34 lalatenduM_ ndevos, yeah saw that thanks :)
13:36 lalatenduM_ ndevos, while testing the patch I found that health_check is failing even for health condition with error " W [posix-helpers.c:1445:posix_fs_health_check] 0-test-vol-posix: open() on /d/testvol-1/.glusterfs/health_check returned: Is a directory"
13:36 lalatenduM_ s/health/healthy/
13:37 ndevos lalatenduM_: uh, and /d/testvol-1/.glusterfs/health_check is a file, I assume?
13:37 lalatenduM_ ndevos, yes
13:38 ndevos lalatenduM_: hmm, strange...
13:41 ndevos lalatenduM_: that open() uses 0666 for permissions, maybe you should use 0644 instead (or actually use: S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH)
13:41 ndevos but I don't think that changes things for the error you get
13:41 lalatenduM_ ndevos, yeah 0644 should be fine actually
13:44 lalatenduM_ ndevos, got it , in the open call, I have given the subvol path, my mistake
13:44 ndevos lalatenduM_: I dont know how you would get EISDIR when the path points to a file and not a dir... maybe I'll test it later
13:44 ndevos lalatenduM_: oh, right
13:44 hagarth joined #gluster-dev
13:45 lalatenduM_ ndevos, for "I think there is a #define for the .glusterfs part of the directory. It is unlikely that this changes, but it would be good to use it." can you point me to an example
13:45 lalatenduM_ s/you/ you plz/ :)
13:47 ndevos lalatenduM_: libglusterfs/src/common-utils.h:#define GF_HIDDEN_PATH ".glusterfs"
13:48 ndevos lalatenduM_: snprintf (file_path, sizeof (file_path), "%s/" GF_HIDDEN_PATH "/health_check", subvol_path)
13:48 skoduri joined #gluster-dev
13:48 ndevos lalatenduM_: or: snprintf (file_path, sizeof (file_path), "%s/%s/health_check", subvol_path, GF_HIDDEN_PATH)
13:49 lalatenduM_ ndevos, thanks @ndevos++
13:51 ndevos you're welcome, lalatenduM_
13:57 _Bryan_ joined #gluster-dev
14:02 jcastillo joined #gluster-dev
14:11 jobewan joined #gluster-dev
14:19 kanagaraj joined #gluster-dev
14:21 wushudoin joined #gluster-dev
14:45 scuttle_ joined #gluster-dev
14:48 bala1 joined #gluster-dev
14:48 vpshastry joined #gluster-dev
14:54 [o__o] joined #gluster-dev
15:05 hchiramm_ joined #gluster-dev
15:07 deepakcs joined #gluster-dev
15:15 ndk joined #gluster-dev
15:16 jdarcy joined #gluster-dev
15:41 skoduri joined #gluster-dev
16:16 skoduri joined #gluster-dev
16:46 lpabon joined #gluster-dev
17:53 vpshastry joined #gluster-dev
18:25 edward1 joined #gluster-dev
19:59 [o__o] joined #gluster-dev
20:00 [o__o] joined #gluster-dev
20:06 shyam joined #gluster-dev
23:20 awheeler joined #gluster-dev

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