Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2016-09-09

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

All times shown according to UTC.

Time Nick Message
00:00 ira I'd have to look... But Samba can go without FS support for locks entirely if we have to. ;)
00:02 ffilzwin ira, would love to hear more about how Samba handles locks. Ganesha will do without FS support also, though it doesn't have any clustering capabilities built in so that's only useful for single node server
00:03 ffilzwin it's also not something configurable or anything...
00:03 ffilzwin but got to go now, and on PTO tomorrow, talk more next week
00:03 ira ffilzwin: Take care :)
01:46 pranithk1 joined #gluster-dev
01:48 ilbot3 joined #gluster-dev
01:48 Topic for #gluster-dev is now Gluster Development Channel - http://gluster.org | For general chat go to #gluster | Patches - http://review.gluster.org/ | Channel Logs - https://botbot.me/freenode/gluster-dev/ & http://irclog.perlgeek.de/gluster-dev/
02:08 EinstCrazy joined #gluster-dev
03:12 ira joined #gluster-dev
03:20 magrawal joined #gluster-dev
03:22 shubhendu joined #gluster-dev
04:05 riyas joined #gluster-dev
04:07 sanoj joined #gluster-dev
04:13 prasanth joined #gluster-dev
04:14 aspandey joined #gluster-dev
04:16 atinm joined #gluster-dev
04:19 kdhananjay joined #gluster-dev
04:19 atinmu joined #gluster-dev
04:35 karthik_ joined #gluster-dev
04:38 rafi joined #gluster-dev
04:47 rastar joined #gluster-dev
04:50 ashiq joined #gluster-dev
04:58 kshlm joined #gluster-dev
04:59 hchiramm joined #gluster-dev
04:59 ndarshan joined #gluster-dev
05:05 kotreshhr joined #gluster-dev
05:05 spalai joined #gluster-dev
05:13 aravindavk joined #gluster-dev
05:16 mchangir joined #gluster-dev
05:18 jiffin joined #gluster-dev
05:21 ndarshan joined #gluster-dev
05:26 pranithk1 joined #gluster-dev
05:41 Saravanakmr joined #gluster-dev
05:47 ppai joined #gluster-dev
05:57 Bhaskarakiran joined #gluster-dev
05:59 ankitraj joined #gluster-dev
06:03 ramky joined #gluster-dev
06:05 nishanth joined #gluster-dev
06:06 jiffin joined #gluster-dev
06:07 atinm joined #gluster-dev
06:11 skoduri joined #gluster-dev
06:14 nigelb Is anyone seeing slowness from review.gluster.org when trying to git pull/push?
06:15 nigelb (atinm reported some slowness. Just checking if it's widespread)
06:20 spalai nigelb: ping time is 280 seconds from my system
06:20 spalai rfc was slow too
06:20 spalai *280ms
06:23 nigelb spalai: thanks. I'll give the gerrit a kick.
06:27 hgowtham joined #gluster-dev
06:39 ppai nigelb: works for me now
06:39 nigelb \o/
06:39 nigelb ppai: reasonable response time?
06:39 ppai nigelb, yes
06:39 nigelb excellent.
06:39 nigelb I wish I had taken a JS stack before the restart :(
06:39 nigelb *java stack
06:45 aspandey joined #gluster-dev
07:07 rraja joined #gluster-dev
07:17 aspandey joined #gluster-dev
07:24 EinstCrazy joined #gluster-dev
07:29 atinm rastar, it seems like http://review.gluster.org/#/c/15375/ didn't work
07:29 rastar atinm: yes, but I figured out the mistake I did
07:30 atinm rastar, ahh whats that?
07:30 rastar atinm: deadlock_fop has a dd command using &
07:31 rastar so it might still be running while the function exits
07:32 rastar I will send a patch now, basically we need a signal from deadlock_fop which monkey_unlock should wait on
07:32 atinm rastar, right
07:32 rastar I will test using a touch file.
07:34 atinm rastar, I think our release branches are also impacted by this test, we need to fix this and get that backported across
07:34 nbalacha joined #gluster-dev
07:34 rastar atinm: oh, ok updating the patch now. Let us see if it works.
07:40 k4n0 joined #gluster-dev
07:40 spalai left #gluster-dev
07:50 pranithk1 joined #gluster-dev
07:51 pranithk1 aravindavk: hey, when should be the RC build date?
07:52 aravindavk pranithk1: I was about ask the same, in yesterday's meeting Action item for us to announce the dates
07:52 pranithk1 aravindavk: 14th is a good date. 2 weeks of testing and we release
07:53 pranithk1 aravindavk: So 14th is RC date. Any more bug fixes etc we will accept till 28th. And by 30th we release
07:53 pranithk1 aravindavk: I am okay to accept feature patches till RC as well
07:55 EinstCrazy joined #gluster-dev
07:56 aravindavk pranithk1: Looks good to me. Can you send mail with the dates to the lists
08:02 EinstCrazy joined #gluster-dev
08:02 pranithk1 aravindavk: I am not sure if my mail would be appropriate because even I want one feature to be taken in :-). So you do it man...
08:03 aravindavk pranithk1: ok
08:03 pranithk1 xavih: You should probably do the backport once aravindavk sends out the mail and people don't disagree...
08:05 xavih pranithk1: thanks. I'll prepare it
08:05 pranithk1 xavih: No, don't prepare it just yet, Only after you don't see lot of opposition with the proposal
08:05 nbalacha joined #gluster-dev
08:06 xavih pranithk1: ok :)
08:09 nbalacha joined #gluster-dev
08:09 devyani7 joined #gluster-dev
08:26 nigelb kshlm: You around?
08:26 nigelb What's going on here -> https://build.gluster.org/job/smoke/30519/console
08:26 nigelb I know this is returning 1, https://github.com/gluster/glusterfs-patch​-acceptance-tests/blob/master/smoke.sh#L63
08:26 atinm ndevos, http://review.gluster.org/#/c/15428/ - can this be taken in for 3.8.4 please
08:26 nigelb But I haven't figured out why.
08:26 nigelb Is it hanging on umount?
08:27 kshlm nigelb, Having lunch, I'll be back in a little while.
08:28 nigelb Sure.
08:29 ndevos atinm: not unless there is a public problem description in https://bugzilla.redhat.co​m/show_bug.cgi?id=1374290
08:29 glusterbot Bug 1374290: medium, medium, ---, bugs, POST , "gluster vol status all clients --xml" doesn't generate xml if there is a failure in between
08:29 EinstCra_ joined #gluster-dev
08:31 atinm ndevos, didn't I clone this bug from mainline?
08:31 atinm ndevos, in mainline I had a public description
08:31 ndevos atinm: no idea, but comment #0 is private
08:32 atinm ndevos, done
08:32 ndevos atinm: thanks!
08:33 EinstCrazy joined #gluster-dev
08:35 EinstCrazy joined #gluster-dev
08:46 nigelb kshlm: for when you're back - https://bugzilla.redhat.co​m/show_bug.cgi?id=1374621
08:46 glusterbot Bug 1374621: unspecified, unspecified, ---, bugs, NEW , Smoke tests fail for no obvious reason
08:51 rastar atinm: nigelb updated fix for netbsd hang http://review.gluster.org/#/c/15375/3
08:52 Saravanakmr joined #gluster-dev
08:52 rastar atinm: nigelb hoping that it would fix, I could reproduce the issue and test multiple times on my laptop. Lets see.
08:52 nigelb Oh good.
08:54 kshlm nigelb, I guess dbench was still running.
08:55 kshlm In https://build.gluster.org/job/smoke/30519/console posix-complicance finishes.
08:56 kshlm But since the job didn't finish at that point, I thinl dbench was still going on.
08:56 kshlm I don't know why dbench was slow.
08:58 nigelb kshlm: can we capture the dbench output?
08:58 nigelb would that interfere with posix compliance?
08:58 nigelb If so, I'd like to send the out put to a file and cat it as part of clean up.
08:59 kshlm Yup you can. Redirect to file instead of /dev/null
08:59 kshlm That shouldn't affect posix compliance.
08:59 kshlm I'm now sure dbench hadn't returned.
09:00 nigelb If it's stuck, I'd like to know why.
09:00 kshlm In the logs is see a `wait %2` which should have waited for dbench.
09:00 kshlm I don't see a subsequent `wait %3` for posix-compliance like in the other logs.
09:02 nigelb But it did finish.
09:02 nigelb That's weird.
09:07 kshlm There is a watchdog that kills everything after 600s.
09:07 kshlm It's not wierd that it finished
09:08 EinstCrazy joined #gluster-dev
09:12 nigelb kshlm: No, the bit that doesn't make sense is that dbench needs only about 2 mins.
09:12 nigelb kshlm: anyway, what's the side effect of removing the `> /dev/null`
09:12 kshlm The logs captured by jenkins will be mixed up.
09:12 nigelb okay, so I'm going to do `> /build/posix-compliance`
09:13 kshlm Both dbench & posix compliance run parallely in the background.
09:13 nigelb and then cat the file in clean up.
09:13 nigelb that should give us both outputs.
09:13 kshlm Sounds good to me.
09:13 nigelb also, https://github.com/gluster/glusterfs-patch​-acceptance-tests/blob/master/smoke.sh#L67 fails
09:13 nigelb there's no /build/install/var/log
09:14 ankitraj left #gluster-dev
09:19 nigelb kshlm: do you know what logs we actually want?
09:20 kshlm smoke.sh tests the file system mainly (only), so the mount and brick logs would be good.
09:21 kshlm No /build/install/var/log? I thought it's using the normal build script.
09:22 nigelb regression gets logs from /var/log/glusterfs
09:24 prasanth joined #gluster-dev
09:37 nigelb kshlm: https://github.com/gluster/glusterfs-​patch-acceptance-tests/pull/60/files
09:42 rafi joined #gluster-dev
09:49 penguinRaider joined #gluster-dev
10:01 pranithk11 joined #gluster-dev
10:12 aspandey joined #gluster-dev
10:16 nbalacha joined #gluster-dev
10:19 ppai_ joined #gluster-dev
10:23 ira joined #gluster-dev
10:25 nbalacha joined #gluster-dev
10:26 rastar joined #gluster-dev
10:28 penguinRaider joined #gluster-dev
10:34 ira joined #gluster-dev
10:38 jiffin joined #gluster-dev
10:48 aspandey joined #gluster-dev
11:06 ashiq joined #gluster-dev
11:07 rastar kdhananjay: do you know what happens when a inode unlock request fails in afr?
11:08 kdhananjay rastar: it just logs the failure and moves on.
11:08 rastar kdhananjay: I am trying to understand http://review.gluster.org/#/c/14816/
11:08 rastar kdhananjay: oh, so it must proceed?
11:09 kdhananjay rastar: proceed? meaning?
11:09 rastar kdhananjay: the commit message says, when the unlock request is lost, dd would get stuck
11:09 kdhananjay rastar: oh, what about the patch?
11:10 rastar ok, if I understand it right, the test case is like this
11:10 rastar kdhananjay: 1. expect dd to hang as unlock was lost
11:11 rastar kdhananjay: 2. write something to the same file from another mount, after 3 seconds and it should succeed as we would have cleaned up the lock
11:11 kdhananjay rastar: right. and after lock-revocation-seconds, things will work
11:11 kdhananjay rastar: correct
11:11 rastar kdhananjay: yes, append will work
11:11 rastar kdhananjay: what would happen to dd?
11:11 kdhananjay rastar: afr would have attempted a blocking lock from the other client, so it would be stuck there.
11:12 kdhananjay rastar: until granted
11:14 rastar kdhananjay: that does not explain the dd part
11:14 rastar kdhananjay: append using echo would wait to get the blocking lock, once granted it would write and finish.
11:15 rastar kdhananjay: dd however would still be trying to unlock a non existing lock is my understanding
11:15 kdhananjay rastar: checking, give me a moment
11:15 rastar kdhananjay: sure
11:17 aspandey joined #gluster-dev
11:17 lkoranda joined #gluster-dev
11:18 kdhananjay rastar: so the way monkey-unlocking works is this:
11:19 kdhananjay rastar: when there is an unlock request (say from the dd in this case), and monkey unlocking is going to be done, locks xl will merely unwind the call as successful without actually removing the unlocked lock from the list of granted locks
11:20 kdhananjay rastar: so dd will still get a response saying the unlock was successful.
11:21 kdhananjay rastar: only when the next lock request arrives, locks xl will put it in the blocked locks list since the "unlocked lock" is actually still very much in the granted list and therefore the appending write lock will be denied/blocoked
11:21 kdhananjay rastar: does that make sense?
11:21 kdhananjay rastar: http://review.gluster.org/#/c/14816/​7/xlators/features/locks/src/inodelk.c
11:21 rastar kdhananjay: cool, that explains how dd hangs
11:22 kdhananjay rastar: ok for unlock to truly succeed, line 704 in the link above neds to be executed.
11:22 kdhananjay rastar: which wont be if monkey-unlocking is done
11:22 kdhananjay (the control returns to the caller at line 656 itself).
11:24 rastar kdhananjay: yes, that is right.
11:24 rastar kdhananjay: what I see is this
11:25 rastar kdhananjay: dd hangs at some point ( which as you explained is for NEXT write on that inode, where the previous write had left a monkey unlocked lock)
11:25 rastar kdhananjay: but even after lock revocation, say, after 3 seconds, dd does not proceed
11:25 rastar kdhananjay: it proceeds only after I do a echo on the file from another mount point
11:26 rastar kdhananjay: I just want to confirm if that is not expected; If not expected, then there is a bug in the code.
11:28 kdhananjay rastar: not sure i understand. dd being a sequential writes utility, once it has unlocked region x-y, it has no reason to lock that region again, and the next lock it would take should be in the range y+1-z and so on.
11:29 rastar kdhananjay: dd doesnot take any lock :)
11:30 rastar kdhananjay: I meant afr taking inode lock for writes that dd performs
11:32 kdhananjay rastar: oh yeah, i meant afr only.
11:33 rastar kdhananjay: is inode_lk region based?
11:34 rastar kdhananjay: ok, and one more bug, locks xlator deciding to do monkey unlock is not a good idea. I see only one of the two replica doing monkey unlock
11:35 kdhananjay rastar: yeah, range based with the exception of (0,0) which means full lock.
11:35 kdhananjay rastar: why is that an issue?
11:36 kdhananjay rastar: the lock from echo would still anyway be blocked even if the blocking lock fails on at least one node
11:36 rastar kdhananjay: oh yes, not an issue because we want at least one lock to remain, not all.
11:36 kdhananjay rastar: so the net effect would be that echo would still be hung
11:37 ira_ joined #gluster-dev
11:37 rastar kdhananjay: what I see is that dd is hung
11:37 kdhananjay rastar: hmm thinking
11:37 kdhananjay rastar: is it consistently recreatable?
11:38 kdhananjay rastar: or at least fairly consistently?
11:38 rastar kdhananjay: yes
11:38 rastar always on my Fedora 24
11:38 kdhananjay rastar: ok could you disable eager-lock in the script?
11:39 kdhananjay rastar: and try again?
11:39 rastar kdhananjay: thanks, let me try that
11:41 nishanth joined #gluster-dev
11:43 rastar kdhananjay: that had no effect.
11:43 rastar kdhananjay: so the problem here is that dd hangs and enters a D+ state
11:43 kdhananjay rastar: okay. might have to capture the statedump on the bricks and analyze it.
11:44 kdhananjay rastar: also needed would be enablement of "trace"ing of locks in afr. let me check
11:45 rastar kdhananjay: yes, I will officially move this to AFR then
11:45 kdhananjay rastar: sure.
11:45 rastar kdhananjay: I have a patch that makes this test pass http://review.gluster.org/#/c/15375/
11:45 rastar kdhananjay: but it looks like I might be defeating the purpose of the test
11:46 rastar kdhananjay: thanks for all the help
11:46 kdhananjay rastar: what;s that? :)
11:46 atinm joined #gluster-dev
11:46 rastar kdhananjay++
11:46 glusterbot rastar: kdhananjay's karma is now 25
11:46 kdhananjay rastar: i only see deletion of all tests in the patch. :)
11:46 aspandey xavih: Hi
11:46 rastar kdhananjay: that is just to make it complete soon, pkalever's idea
11:47 xavih aspandey: hi
11:47 rastar kdhananjay: you need to look at the only test remaning tests/features/lock_revocation.t
11:47 pkalever rastar: :)
11:48 kdhananjay rastar: ok will take a look sometime. its bash. (i suck at it ;) )
11:49 rastar kdhananjay: no problem.
11:56 aspandey xavih: regarding http://review.gluster.org/#/c/13733/​18/xlators/cluster/ec/src/ec-common.c@1066
11:57 aspandey xavih: This is a valid case..
11:59 aspandey xavih: But do we need to block ALL the update fop? if yes then at what point?
12:02 xavih aspandey: I think we cannot allow any new fop that requires metadata (lock->query) or updates data/metadata (link->update[*] != 0) while a previous fop has issued an xattrop
12:04 xavih aspandey: however this is problematic: if we get all information in a single xattrop, even if we don't need it yet, create and similar fops will not create files on some bricks though it should
12:04 xavih aspandey: but if we defer metadata loading until it's really needed, we could need two xattrops, making the logic to control all this more complex
12:06 xavih aspandey: however, this second case doesn't solve the first problem either because a create, failed setxattr and create will create the last file only in "good" bricks
12:08 xavih aspandey: I think we should track two good_mask's, one for fops that require matching metadata information (read/write), and one for fops that don't require it (create/mkdir)
12:08 xavih aspandey: computing the second mask could be tricky, however this simplifies the first problem a lot because we only need to manage a single xattrop
12:08 aspandey xavih: Thinking... Actually this part is always confusing to me. I discussed it with Pranith and somehow got convinced  . But the case you have mentioned,of create, it has again confused me..
12:09 aspandey xavih: which is valid case and create issue..
12:10 xavih aspandey: wait, we won't be able to always work with a single xattrop. A read fop could arrive that only needs to query metadata, later a create fop will need an additional xattrop to update dirty
12:11 xavih aspandey: in worst case, we'll have to manage 3 xattrops: 1 for reading information, 1 for updating metadata dirty and 1 for updating data dirty
12:12 xavih aspandey: Additionally we'll also need to solve the create problem when metadata has already been read. I'll need to think about this in more depth...
12:12 xavih aspandey: what confuses you ?
12:23 aspandey xavih: My confusion was mainly with the sequence of fops and the type of fop. I thought two update fop will never come at this point. Probably, I have to dig deeper in to EC locks.
12:24 xavih aspandey: oh, you are right. Currently, update fops are not allowed to be executed in parallel
12:25 xavih aspandey: I'm planing to change this, but right now you are right. Sorry for the confusion... :(
12:25 aspandey xavih: This is what Pranith also mentioned...
12:27 xavih aspandey: this simplifies the problem for now...
12:27 hagarth joined #gluster-dev
12:28 xavih aspandey: when dirty update is needed, we are sure that the metadata read, if any, has already been completed by a previous read or write fop
12:28 kdhananjay joined #gluster-dev
12:28 xavih aspandey: so, yes, we can only have one xattrop executing simultaneously
12:30 aspandey xavih: ok. This part looks very sensitive to me :)
12:31 xavih aspandey: I'll need to review the patch again with this in mind. I didn't have this present when reviewing it last time... sorry...
12:33 aspandey xavih: No problem. But I depend on you and Pranith on this for now. I certainly have to further understand ec locks in depth.
12:33 xavih aspandey: don't worry :)
12:35 aspandey xavih: I am sending this patch again after implementing your other comments except this. You can review it after that.
12:35 xavih aspandey: great :)
12:46 rafi joined #gluster-dev
12:51 shyam joined #gluster-dev
13:11 devyani7 joined #gluster-dev
13:16 ashiq joined #gluster-dev
13:17 spalai joined #gluster-dev
13:24 shyam joined #gluster-dev
13:28 Muthu_ joined #gluster-dev
13:35 spalai left #gluster-dev
13:39 devyani7 joined #gluster-dev
13:55 baojg joined #gluster-dev
14:18 ramky joined #gluster-dev
14:21 penguinRaider joined #gluster-dev
14:46 hagarth joined #gluster-dev
14:48 wushudoin joined #gluster-dev
15:00 jobewan joined #gluster-dev
15:18 hagarth joined #gluster-dev
15:20 cholcombe joined #gluster-dev
15:20 prasanth joined #gluster-dev
15:23 shyam joined #gluster-dev
15:29 shaunm joined #gluster-dev
16:07 hagarth joined #gluster-dev
16:29 ndevos nigelb: something is broken in Jenkins... https://build.gluster.org/job/release/169/console failed unexpectedly :-/
16:33 devyani7 joined #gluster-dev
16:34 ndevos thats not reported as https://bugzilla.redhat.co​m/show_bug.cgi?id=1374798
16:34 glusterbot Bug 1374798: urgent, unspecified, ---, bugs, NEW , Jenkins job for creating a release tarball fails, release of glusterfs-3.8.4 blocked
16:35 misc ndevos: mhh, should it be build in mock ?
16:36 ndevos misc: no, it builds from a git checkout and generates the source tarball
16:36 misc ndevos: that's a security issue then
16:36 ndevos misc: well, it probably could be done in mock or some chroot, but that is not the case atm
16:37 misc I can fix it for now, but we shouldn't run any jobs on master
16:37 misc ndevos: I installed libxml2
16:38 ndevos misc: well, I dont care where it runs... no idea how mock can do git-clone+checkout, thats something we need to look into
16:39 ndevos misc: https://build.gluster.org/job/release/170/console is running now, hopefully nothing else is missing...
16:40 ndevos in case something else is missing, we will likely hear it from users building from the tarball, oh well
16:42 pranithk1 joined #gluster-dev
16:43 shaunm joined #gluster-dev
16:43 pranithk1 joined #gluster-dev
16:43 pranithk1 joined #gluster-dev
16:46 misc ndevos: seems the job did work
17:30 nigelb That looks like you just needed libxml2-devel
17:30 nigelb (sorry, it's too late for me to be here)
17:30 nigelb Thanks for fixing it up, misc
17:43 kotreshhr left #gluster-dev
17:52 penguinRaider joined #gluster-dev
18:17 aspandey joined #gluster-dev
19:05 hagarth joined #gluster-dev
20:48 dlambrig_ joined #gluster-dev
21:07 shyam joined #gluster-dev
23:04 wushudoin joined #gluster-dev

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