- Wednesday, June 29, 2016

release-team@conference.openafs.org

Wednesday, June 29, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[00:32:21] mvita leaves the room
[01:31:09] mvita joins the room
[02:15:58] mvita leaves the room
[02:27:34] mvita joins the room
[02:48:12] mvita leaves the room
[03:18:54] mvita joins the room
[03:50:04] mvita leaves the room
[07:05:12] Jeffrey Altman leaves the room
[07:05:12] Jeffrey Altman joins the room
[07:38:26] mvita joins the room
[07:47:15] mvita leaves the room
[09:00:01] Jeffrey Altman leaves the room
[09:01:48] Jeffrey Altman joins the room
[12:16:02] mvita joins the room
[12:59:33] meffie joins the room
[13:29:50] mvita leaves the room
[13:31:07] mvita joins the room
[13:59:11] wiesand joins the room
[14:00:18] <wiesand> Hello craowd
[14:00:26] <wiesand> er, crowd
[14:03:04] <mvita> howdy
[14:03:20] <mvita> meffie should be here shortly
[14:03:33] <mvita> we get jammed up w/ the previous 9:30 mtg
[14:03:50] <wiesand> Hi Mark. That’s fine.
[14:03:53] <mvita> how are you, Stephan?
[14:04:09] <wiesand> Busy... but well. How are you?
[14:04:13] <meffie> hello
[14:04:22] <wiesand> Hello Mike.
[14:04:32] <mvita> very busy.  you will be happy to know that much of the business was on your behalf (getcwd)
[14:04:43] <wiesand> Ah :)
[14:04:54] <mvita> no answer yet, but I am close
[14:05:15] <wiesand> Sounds good. So, is it dentry revalidation?
[14:05:26] <mvita> actually, I think it is not
[14:05:36] <mvita> we always say it's valid when asked
[14:05:42] <wiesand> Oh.
[14:06:10] <mvita> so I believe someone else invalidated it - which would mean linux, or AFS as a side effect (instead of direct invalidation)
[14:06:18] <wiesand> NB can I remove the directory with the traces etc. from last week?
[14:06:37] <mvita> yes, thank you.
[14:06:59] <mvita> they were very helpful to get me started,but I don't need them any more
[14:07:08] <wiesand> thanks
[14:07:39] <wiesand> Have you found any other way to provoke the problem?
[14:08:06] <mvita> yes.
[14:08:27] <mvita> I don't need to do git checkout any more\
[14:08:35] <mvita> a git grep + git log will do it
[14:08:40] <mvita> (for me)
[14:09:08] <mvita> the key is to get a lot of vcaches active in a short amount of time
[14:09:28] <mvita> and then afs_ShakeLoose comes along and rips them all out again
[14:09:29] <meffie> `find` should be able to do that too.
[14:09:43] <mvita> so this is not a shakeloose bug, I don't think
[14:10:05] <mvita> but I do believe it is more easily provoked now that shakeloose is working better
[14:10:07] <wiesand> shaking harder now just uncovers another bug?
[14:10:17] <wiesand> so yes :)
[14:10:18] <mvita> yes, that's my belief
[14:10:34] <mvita> I confirmed this by reducing shakeloose period from 300s to 90s
[14:10:47] <mvita> and now I don't have to wait 180s for the failure
[14:11:03] <wiesand> not at all? or still some?
[14:11:09] <mvita> not much
[14:11:44] <mvita> it varies because you don't know when shakeloose is running - I added some trace entries to help with that
[14:11:58] <wiesand> Why would 300s require a wait > 120s but 180s is sufficient?
[14:12:20] Daria joins the room
[14:12:37] <mvita> it's just an average thing - when you add 180s to the run time of your setup test, it guarantees at least 1 shakeloose has run
[14:13:07] <mvita> (almost) guarantees
[14:13:21] <wiesand> ok
[14:13:29] <mvita> there may also be an interaction w/ cache truncation daemon, still working that angle
[14:13:48] <mvita> that is also a period housekeeping task that is seen in the traces when this occurs
[14:13:58] <mvita> runs on a different schedule than shakeloose
[14:14:14] <mvita> s/period/periodic
[14:15:21] <wiesand> If it’s shakeloose, -disable-dynamic-vcaches should make the issue disappear?
[14:15:27] <mvita> so that's all I have to report on that for now.
[14:15:37] <mvita> that's a thought, I'll try that.
[14:16:06] <wiesand> Thanks for looking into this!
[14:16:19] <mvita> but that might expose other issues on Linux... no one I know runs that way, so the alternate code doesn't have a lot of miles on it
[14:17:14] <mvita> shakeloose still runs without dynamic vcaches, it just behaves differently
[14:17:24] <mvita> and is run differently
[14:17:25] <wiesand> I have an SL5 machine which has been running the afs client with that flag for years
[14:18:32] <mvita> what's the AFS version there?
[14:19:07] <wiesand> The client was hogging a lot of memory which I wanted to have spent on something else (fs cache)
[14:19:14] <mvita> yeah.
[14:19:18] <wiesand> 1.4.15 + security backports
[14:19:27] <mvita> SL5 is not old enough to have a 2.4 kernel, is it?
[14:19:32] <wiesand> it si
[14:19:48] <wiesand> er, no..
[14:19:52] <wiesand> 2.6.18
[14:19:56] <mvita> okay
[14:20:55] <mvita> but still... running current versions of openafs on linux w/out dynamic vcaches might be ... interesting.
[14:21:19] <mvita> I'll try it and let you know what I find
[14:21:40] <mvita> it's a good idea for a workaround and will help me narrow down some things
[14:23:01] <wiesand> I guess not much has happened otherwise?
[14:23:20] <wiesand> I saw you +1’ed 12297 today
[14:23:22] <mvita> as long as we are discussing Linux stuff... I will venture to speak for Joe and say he is working on re-enabling splice() for 4.4
[14:23:41] <mvita> just research at this point - he reenabled it to allow for some testing
[14:23:42] <wiesand> Ah, that would be nice.
[14:24:10] <wiesand> Do we believe 12297 is all we need for 4.6?
[14:24:54] <mvita> as far as we know... I don't think that's saying a whole lot.
[14:25:26] <mvita> I don't know who has tested it "in anger", as they say in London
[14:25:52] <wiesand> London? Where’s that?
[14:25:58] <mvita> heh
[14:26:16] <mvita> some obscure little island realm
[14:26:37] <meffie> heh
[14:26:40] <mvita> ;-)
[14:26:44] <wiesand> It rings some bell, but I can’t seem to remember ;-)
[14:27:01] <mvita> maybe it will come to you later, but we digress...
[14:27:13] <wiesand> Right.
[14:27:39] <wiesand> By any chance, has Joe looked at 4.7rc?
[14:27:52] <mvita> checking my notes.... stand by
[14:28:56] <mvita> I don't think so.   I did (from a high level review of the changelogs, not building or running code on 4.7)
[14:29:02] <mvita> and passed my notes on to Joe
[14:29:35] <mvita> I did some preliminary work on whether AFS will be able to tolerate parallel directory reads and lookups in 4.7
[14:30:16] <mvita> the AFS_GLOCK and our other locks should provide some protection, but I don't know if it's adequate yet.
[14:30:22] <mvita> so that's an open research question
[14:30:38] <wiesand> Thanks for the "good" news...
[14:32:38] <mvita> we are playing catch-up ball (an american baseball expression) but we _are_ catching up, I think.
[14:34:22] <wiesand> It’s great that you’re doing this. Without this effort, openafs would become completely irrelevant very quickly.
[14:35:24] <mvita> I'm glad you are encouraged by the effort.  Did you want to talk about 1.6.x at all?
[14:35:48] <mvita> (well, I guess the getcwd is for 1.6.x)
[14:35:54] <mvita> anything else?
[14:36:46] <wiesand> Well, looking at gerrit... probably not?
[14:37:09] <mvita> I only got to a few gerrits this week, sorry
[14:37:41] <mvita> I have to sleep sometime ^o)
[14:38:28] <wiesand> There;s nothing particularly urgent, right?
[14:39:06] <mvita> I'm treating the getcwd as urgent; other than that, I can't think of anything urgent in gerrit for 1.6.x
[14:39:08] <wiesand> At least nothing that we could actually get done anytime soon
[14:39:13] <mvita> (well, the unmentionable)
[14:39:22] <mvita> still nothing heard on that
[14:39:50] <wiesand> yes, the unmentionable, but that has been around forever
[14:40:09] <wiesand> maybe RECFOUNDDB
[14:40:11] <mvita> true.  nevertheless, could you do some poking on that?
[14:40:27] <mvita> ah, yes, thank you, the ubik stuff needs to go in
[14:41:59] <wiesand> re poking, I think it will need quite a bit of Ben’s time
[14:42:30] <mvita> well, he does have deputies
[14:43:00] <mvita> but yes, a lot of time no matter how you slice it
[14:45:22] <wiesand> Last plan I heard of was to add it late before the 1.6.19 release
[14:45:56] <mvita> recfounddb?
[14:46:05] <wiesand> the unmentionable
[14:46:14] <mvita> oh, I didn't even hear that.
[14:47:03] <mvita> anyway, I will review 12281 fwiw - not an ubik expert at that level, but I can look
[14:48:44] <wiesand> hm, maybe it was in a dream
[14:49:06] <mvita> HEH!
[14:51:08] <wiesand> Ben said he’d be unusually busy for all of June.
[14:53:16] <mvita> okay, so no 1.8 talk today.
[14:53:41] <mvita> and maybe we should just let sleeping unmentionables lie until he's not so busy
[14:53:44] <wiesand> Unlikely, unless you have something to bring up?
[14:53:56] <mvita> no, nothing from me for 1.8
[14:54:29] <wiesand> I’d like to give it some more time, and not poke at such times
[14:54:37] <mvita> agreed
[14:55:00] <wiesand> I do understand your urge to get it done though
[14:55:17] <wiesand> I just can’t help it
[14:56:10] <mvita> I've got nothing further.
[14:56:50] <wiesand> Ok, let’s adjourn. Thanks a lot again for working on the linux client issues!
[14:56:59] <mvita> you are very welcome.
[14:57:12] <mvita> have a good week
[14:57:31] <mvita> and thank you for your work on coordinating these mtgs and 1.6.x
[14:57:40] <wiesand> you too.
[14:58:08] <wiesand> and well, I could have been better at that lately :-(
[14:58:32] <mvita> nah - you have to sleep some time!
[14:58:46] <meffie> thanks
[14:59:10] <wiesand> cu next week then
[14:59:12] <wiesand> bye
[14:59:13] wiesand leaves the room
[15:01:52] meffie leaves the room