- Wednesday, July 6, 2016

release-team@conference.openafs.org

Wednesday, July 6, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[13:48:01] meffie joins the room
[13:54:08] meffie leaves the room
[13:54:09] meffie joins the room
[14:00:57] wiesand joins the room
[14:01:12] <wiesand> Hello
[14:01:12] kadukoafs@gmail.com/barnowl4B0829E7 leaves the room
[14:01:12] kadukoafs@gmail.com/barnowl93AC7D46 leaves the room
[14:01:12] kadukoafs@gmail.com/barnowl4B0829E7 leaves the room
[14:01:12] kadukoafs@gmail.com/barnowl4B0829E7 leaves the room
[14:01:12] kadukoafs@gmail.com/barnowl4B0829E7 leaves the room
[14:01:57] kadukoafs@gmail.com/barnowl0226D601 joins the room
[14:02:34] <kadukoafs@gmail.com/barnowl0226D601> Good morning.
Could you please send a test message to the openafs room to boot me there as
well?
[14:03:11] <mvita> hi
[14:04:44] <wiesand> let’s briefly go through our list of linux issues
[14:05:10] <wiesand> The cwd problem goes away when I revert "shake harder".
[14:05:37] <wiesand> Do we have a better solution for this?
[14:05:40] <mvita> makes sense - it gets worse (happens faster) when I increase the frequency
[14:05:56] <mvita> not yet, and reverting shakeloose doesn't really fix it
[14:06:08] <mvita> it's just exposing a problem that was already there
[14:06:16] <mvita> before shakeloose started working properly
[14:06:25] <kadukoafs@gmail.com/barnowl0226D601> reverting shakeloose only on the stable branch could be a valid
release engineering tradeoff, though
[14:06:26] <mvita> that's my current working theory
[14:07:07] <wiesand> And it’s good that we found it now. I’d still like to issue a release which works as well as pre-1.6.18 did in this respect quickly.
[14:07:34] <wiesand> Like Ben says...
[14:07:46] <mvita> I haven't been able to devote any time to getcwd since the last mtg, but I will get back to it later today.
[14:07:50] <wiesand> shake harder fixes a problem, but in umasks a worse one
[14:09:33] <wiesand> Proposal: Put the revert change for 1.6 into gerrit today so downstream can pick it up there.
[14:09:52] <kadukoafs@gmail.com/barnowl0226D601> I guess you could prepare a --
you read my mind
[14:09:54] <mvita> well, since I don't have root cause yet, I can't estimate how long a real fix might take, so perhaps reverting is the best option right now
[14:10:32] <wiesand> And release a fixed 1.6.18.2 next Wednesday. With whatever we have at that point. Either the revert or a real fix which is by then reviwed and tested.
[14:10:53] <mvita> I know the cwd dentry got unhashed, but I don't know how.
[14:11:16] <mvita> so it might be time for some systemtap foo
[14:13:27] <wiesand> What else could go into 1.6.18.2?
[14:13:48] <wiesand> Has Joe made progress on reenabling splice()?
[14:15:12] <wiesand> Was 12297 actually tested, and is it believed to be the only fix we need for Linux 4.6?
[14:15:14] <mvita> I don't know
[14:15:35] <kadukoafs@gmail.com/barnowl0226D601> We have reports from people on IRC of at least tentative success.
[14:15:43] <kadukoafs@gmail.com/barnowl0226D601> It's also in Debian+Ubuntu.
[14:16:14] <kadukoafs@gmail.com/barnowl0226D601> Hmm, let me push the 'rebase' button so buildbot verifies it.
[14:16:23] <wiesand> Do Debian + Ubuntu revert shake hadrer yet?
[14:16:23] <mvita> I just pinged joe to see if he can join us
[14:16:23] <meffie> as far as i know 12297 is all we needed for 4.6
[14:16:43] <wiesand> So that would be a nice addition...
[14:16:49] <kadukoafs@gmail.com/barnowl0226D601> Debian still has shake harder; I assume ubuntu also does, but am not
directly responsible for that.
[14:16:50] <mvita> he's on his way
[14:17:57] <wiesand> Ben, we should probably pull up 12321?
[14:18:00] <kadukoafs@gmail.com/barnowl0226D601> I expect to be able to merge 12297 to master this week; I just want to
double-check the claim about PAGE_* being available wherever
PAGE_CACHE_* are.
[14:18:17] <kadukoafs@gmail.com/barnowl0226D601> Yes, 12321 should get a pullup.
[14:18:43] <kadukoafs@gmail.com/barnowl0226D601> (Unless you like overriding buildbot all the time or something ;) )
[14:18:56] <wiesand> 12239 is another 1.6.18.2 candidate
[14:20:10] <kadukoafs@gmail.com/barnowl0226D601> Yeah, it's on my list to look at, but I have less confidence that it
will be merged than the linux-4.6 thing.
[14:20:35] <kadukoafs@gmail.com/barnowl0226D601> (In that it's longer and I haven't looked at it much yet)
[14:21:02] jgorse joins the room
[14:21:11] <wiesand> It has very limited potential to break anything
[14:21:21] <mvita> howdy Joe.
[14:21:26] <jgorse> hello
[14:21:28] <wiesand> Hi
[14:21:29] jgorse reads
[14:21:30] <mvita> can you see any scrollback?
[14:23:21] <kadukoafs@gmail.com/barnowl0226D601> (logs at
https://conference.openafs.org/release-team@conference.openafs.org/2016-07-06.html)
[14:23:44] jhg joins the room
[14:24:31] <jhg> wiesand: 12297 was tested with robotest
[14:25:27] <wiesand> So some tests were run on Linux 4.6 with it applied?
[14:26:04] <jhg> kadukoafs_gmailcom: that's fair. FWIW, on the linux kernel xref search, I found this to be a valid assumption.
[14:26:54] <jhg> wiesand: correct. basic functionality.
[14:27:29] <wiesand> Thanks
[14:27:34] <jhg> welcome
[14:27:54] <wiesand> Has anyone looked at 4.7 yet?
[14:28:29] <wiesand> The last rc received a CVE today, so it will probably take a week more, but it’s not far out.
[14:28:37] <jhg> wiesand: it's on my list. I have not had a chance to try it yet.
[14:29:08] <mvita> I have not tried it either.  The changes are said to be "smaller" than 4.6
[14:29:16] <mvita> ymmv
[14:30:03] <mvita> there is supposed to be new ability to perform readdir and lookup operations in parallel
[14:30:41] <mvita> I started looking at the OpenAFS code to see if we are sufficiently serialized (by AFS_GLOCK et al) to tolerate parallel operations
[14:30:45] <mvita> but I didn't get far.
[14:30:48] <kadukoafs@gmail.com/barnowl0226D601> I think that the change I made in
360f4ef53c454494cd5212a5ea46c658bdb2879c was needed to avoid breakage
with the support for the parallel readdir/lookup
[14:31:44] <mvita> ahh, I didn't realize the connection there
[14:31:57] <meffie> oh, the "full circle" patch :)
[14:32:04] <kadukoafs@gmail.com/barnowl0226D601> Well, I'm not sure, but I knew there was a plan to switch them over
for something.
[14:32:18] <kadukoafs@gmail.com/barnowl0226D601> I haven't pulled from linux.git in quite some time to look.
[14:32:32] <mvita> 4.7 also continues to lay groundwork for 64-bit timestamps in VFS
[14:32:54] <mvita> I did a little reading on that today and identified a few changes OpenAFS will need for 4.8
[14:35:18] <wiesand> More bad news, but thanks for the heads up
[14:35:41] <mvita> it's not bad news, the changes are mechanical
[14:36:15] <mvita> and quite small (so far)
[14:36:20] <mvita> I'm not done looking yet.
[14:37:18] <wiesand> pullup of 12321 is 12322
[14:38:13] <wiesand> and the revert is 12323 - please feel free to add a proper description of the problem to the commit message
[14:40:15] <wiesand> ok, so much for our beloved Linux client
[14:40:41] <meffie> time to switch to *bsd?
[14:40:54] <jhg> meffie: I am ready
[14:41:18] jgorse leaves the room
[14:41:53] <jhg> they recently rewrote their sendfile for us: https://svnweb.freebsd.org/base?view=revision&revision=293439
[14:41:56] <wiesand> how important is 12315?
[14:43:46] <wiesand> Does it affect just the "fs" command?
[14:45:05] <mvita> looking
[14:45:51] <meffie> yes, just fs
[14:45:54] <mvita> it's just userspace memory, freed as soon as fs exits anyway, I think
[14:46:21] <meffie> yes
[14:46:33] <wiesand> not exactly urgent then. thanks
[14:46:36] <mvita> so nice catch, but not urgent
[14:47:20] <wiesand> So let’s focus on 1.6.18.2 for the time being. We won’t get much more done anyway.
[14:47:31] <wiesand> Ben, on to 1.8?
[14:48:42] <kadukoafs@gmail.com/barnowl0226D601> Hmm.
[14:48:51] <kadukoafs@gmail.com/barnowl0226D601> I merged a couple of tiny things, but nothing very interesting.
[14:49:49] <meffie> thank you.
[14:50:19] <kadukoafs@gmail.com/barnowl0226D601> I think the main things that are unknowns are who is going to do the
updates for the StaleVCache and ubik patchsets
[14:51:48] <mvita> ubik-pio?
[14:52:31] <mvita> I think I need to take the dvhint / stalevcache
[14:52:44] <mvita> since I have an internal ticket that relates directly
[14:53:30] <mvita> and I'm already familiar with it
[14:54:17] <mvita> which ubik stuff?
[14:54:42] <meffie> prob read-while-write
[14:54:43] <mvita> oh, recfounddb, right?
[14:54:57] <mvita> no, we're good for read-while-write since you disabled it in master'
[14:55:07] <meffie> ok.
[14:55:19] <mvita> but I am actively working on fixing that this week
[14:55:38] <mvita> again, internal ticket
[14:56:36] <mvita> if I get a fix, I will push it to master to reenable
[14:57:18] <mvita> I have root cause, but the solution is gonna be tricky.
[14:58:20] <mvita> ubik is layer-happy
[15:00:10] <wiesand> Looks like we’re done for today?
[15:00:36] <mvita> well, Ben never did say which ubik stuff he was speaking of
[15:00:59] <meffie> i think andrew's fixes.
[15:01:21] <wiesand> 12281 & company?
[15:01:25] <mvita> okay, yeah, you're probably right.
[15:01:39] <meffie> yes
[15:01:50] <mvita> I can't take those on right now.
[15:02:22] <wiesand> 11793 seems hopeless too
[15:02:26] <meffie> i need to review those closely.
[15:02:54] <mvita> 11793 is mine now
[15:03:04] <mvita> everything in linux-dvhint
[15:03:10] <meffie> it's not hopeless, just a pain.
[15:03:20] <mvita> yes, painage galore
[15:03:46] <wiesand> next Xmas...
[15:04:04] <mvita> Stephan, settle.
[15:04:07] <mvita> ;-)
[15:04:45] <wiesand> let’s face it?
[15:05:04] <mvita> you know me - never give up.
[15:05:33] <wiesand> Yes, valiant...
[15:06:30] <kadukoafs@gmail.com/barnowl0226D601> Sorry, was in another meeting.  Let me get those gerrit numbers for
the ubik bits...
[15:06:53] <mvita> 12281 and friends?
[15:07:29] <kadukoafs@gmail.com/barnowl0226D601> Oh, and I also wanted to ask about DEBUG_BITMAP (11985), is that a
priority for you?
[15:07:48] <mvita> no.
[15:07:55] <kadukoafs@gmail.com/barnowl0226D601> Yeah, 12281 and 12283 are the ones I have open.
[15:07:57] <mvita> it's just a developer test tool
[15:08:09] Daria joins the room
[15:08:19] <kadukoafs@gmail.com/barnowl0226D601> (noting that there are also subsequent related changes)
[15:08:44] <mvita> I can rebase those without 11985 if you like
[15:08:45] <kadukoafs@gmail.com/barnowl0226D601> Okay, I will de-prioritize debug-bitmap
[15:09:30] <kadukoafs@gmail.com/barnowl0226D601> Oh, I was thinking about the ubik ones for subsequent changes.
But yeah, if you have a chance, I would look at the type consistency
things.
[15:10:15] <kadukoafs@gmail.com/barnowl0226D601> It's not entirely clear to me the status of Jeff's objections on 10447
at this point
[15:11:52] <mvita> trying to remember what I did in ps5 for that...
[15:13:23] <mvita> ugg, gerrit UI
[15:15:41] <meffie> looks like you converted to VnodeId everywhere in that patchset
[15:16:12] <mvita> okay, how do I get gerrit to show me that?
[15:16:41] <meffie> for example dumpstuff.c was changed
[15:17:06] <meffie> you select a file, then the numbers on the top.
[15:17:34] <mvita> right - but which numbers?   I'm trying 4 on the left and 5 on the right
[15:17:41] <mvita> is that the way it should work?
[15:18:08] <meffie> yes, and then 3 and 4
[15:18:57] <meffie> you can see the changes to dumpstuff.c (for example) happend in ps 5
[15:18:57] <mvita> it's impossible to tell which one is selected (except by looking at the generated URL)
[15:19:09] <mvita> so annoying
[15:19:18] <meffie> the numbers are highlighted.
[15:19:41] <mvita> I cannot detect any highlight whatsoever
[15:19:43] <meffie> and the url is updated to show the ps numbers
[15:20:02] <mvita> yes, the URL is the only thing I can see
[15:22:45] <kadukoafs@gmail.com/barnowl0226D601> So, on the main page (e.g., https://gerrit.openafs.org/#/c/10447/5),
there's a dropdown in the top right (just left of 'download') that
lets you select a different (older) version of the patchset to view.
There's also a thing under the commit summary and above the "changed
files" portion, that has a "Diff against" dropdown to select the base
of the diff.
[15:25:32] <kadukoafs@gmail.com/barnowl0226D601> On the per-file page, you can also select which version should be the
left and which should be the right, which is where the "just-barely
highlighted" part comes in.
[15:26:11] <mvita> that's the one that is most useful to me, since I want to compare 4 to 5
[15:26:24] <mvita> but that highlighting .....
[15:26:42] <mvita> I'll just have to deal.  Thanks for the help, Mike and Ben.
[15:26:58] <kadukoafs@gmail.com/barnowl0226D601> http://web.mit.edu/kaduk/Public/gerrit-highlighted.png has how the
highlighting works for me
[15:27:23] <kadukoafs@gmail.com/barnowl0226D601> Of course, there's also the issue that things can be completely junk
if you've rebased between the patchsets, since it's basically showing
the 'git diff' output.
[15:27:40] <kadukoafs@gmail.com/barnowl0226D601> In that case you have to do something ugly like diff <(git show <LHS>)
<(git show <RHS>)
[15:27:43] <mvita> I honestly can't tell which one is highlghted there either
[15:27:59] <mvita> I guess I need to get better glasses
[15:28:18] <kadukoafs@gmail.com/barnowl0226D601> (The '4' has a light blue square around it.)
[15:28:30] <mvita> I cannot see that on my monitor.
[15:29:30] <mvita> AHHH − but I can on my laptop screen!
[15:29:31] <kadukoafs@gmail.com/barnowl0226D601> Hmm, maybe you can override the CSS for <a
class="com-google-gerrit-client-diff-PatchSetSelectBox_BinderImpl_GenCss_style-selected"?
[15:29:58] <mvita> I need to adjust my monitor somehow - I bet it needs more bitplane depth
[15:33:08] <meffie> .com-google-gerrit-client-diff-PatchSetSelectBox_BinderImpl_GenCss_style-selected {
    font-weight: bold;
    background-color: red;
[15:34:27] <meffie> maybe add some blink tags and send a patch to gerrit.
[15:34:39] <mvita> okay.
[15:34:48] <mvita> :-P
[15:37:43] <mvita> recalibrated the monitor and now the highlight is visible
[15:37:45] <mvita> yay
[15:37:54] <kadukoafs@gmail.com/barnowl0226D601> yay
[15:39:03] <meffie> woot
[15:39:27] <mvita> now I have to find something new to whine about
[15:39:46] <kadukoafs@gmail.com/barnowl0226D601> Surely it's those kids on your lawn?
[15:39:57] <mvita> not again.
[15:40:36] <mvita> ;-)
[15:41:01] <meffie> heh
[15:42:08] <mvita> okay, I think we are done here.
[15:42:23] <meffie> have a good day.
[15:42:51] <mvita> as far as I can tell, objections to 10447 have been addressed in ps5
[15:44:04] <kadukoafs@gmail.com/barnowl0226D601> You, too.
[15:44:24] <kadukoafs@gmail.com/barnowl0226D601> > as far as I can tell, objections to 10447 have been addressed in ps5
That's my assumption as well; I was mostly seeing whether jaltman
would pop up and say otherwise.
[15:48:47] jhg leaves the room
[15:48:56] jhg joins the room
[15:57:25] <wiesand> I was mostly distracted during the 1.8 part, but it seems you made some progress. Good :)
[15:57:52] <wiesand> And I have to run now. Thanks a lot for being here today!
[15:58:06] <wiesand> Goodbye
[15:58:07] wiesand leaves the room
[15:58:20] <jhg> ciao
[15:59:10] <kadukoafs@gmail.com/barnowl0226D601> Thanks
[16:00:52] meffie leaves the room
[22:04:19] Jeffrey Altman leaves the room
[22:07:45] Jeffrey Altman joins the room
[23:17:34] Jeffrey Altman leaves the room
[23:17:34] Jeffrey Altman joins the room
[23:33:25] mvita leaves the room
[23:35:01] mvita joins the room
[23:39:23] mvita leaves the room