- Friday, June 15, 2018

release-team@conference.openafs.org

Friday, June 15, 2018< ^ >

Room Configuration

Room Occupants

GMT+0
[12:28:24] Marcio Barbosa joins the room
[12:38:27] <kaduk@jabber.openafs.org/barnowl> [test message; please ignore]
[13:00:27] wiesand joins the room
[13:00:36] <wiesand> [ok]
[13:01:26] <kaduk@jabber.openafs.org/barnowl> greetings [please do not ignore]
[13:01:34] <wiesand> Hell
[13:01:38] <wiesand> o
[13:02:31] <kaduk@jabber.openafs.org/barnowl> Thanks for being vigilant about 1.8 pullups!
[13:03:10] <wiesand> Thanks for merging them!
[13:03:51] <wiesand> Not sure about pulling up the mcas one…
[13:04:19] <wiesand> I'm also not quite sure what should make it into 1.6 at this point.
[13:04:19] meffie joins the room
[13:04:28] <wiesand> I have a mind to reject https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:openafs-stable-1_6_x+topic:dcache-panic-rocache
[13:04:34] <kaduk@jabber.openafs.org/barnowl> Yeah, the mcas one would be a bit tough.
[13:05:29] <meffie> good morning.
[13:05:39] <wiesand> Hello Mike
[13:06:06] <kaduk@jabber.openafs.org/barnowl> The 1.6 dcache-panic-rocache is not a clear reject to me, but I see
where you're coming from.
[13:07:03] <meffie> dcache-panic-rocache does address a panic if the cache partition is mounted -o ro
[13:07:16] <meffie> which can happen by the os
[13:07:42] <wiesand> Well, when this happens it's either pilot error, or the cache fs is wedged anyway.
[13:08:04] <meffie> yeah, it's not a new problem.
[13:08:34] <meffie> but losing the whole machine is pretty terrible.
[13:08:46] <kaduk@jabber.openafs.org/barnowl> Yeah.
[13:08:57] <wiesand> depends on the point of view
[13:09:18] <meffie> i'm not sure it is urgent, maybe it could be in the next 1.6.x release?
[13:09:18] <wiesand> a dead system can be much better than a wedged one
[13:09:51] <kaduk@jabber.openafs.org/barnowl> Fun story: we had a solaris machine with like 2000 days of uptime, and
needed to do some maintenance.  Stopping AFS seemed to work fine, as
did unloading the kernel module.  Alas, attempting to grep for
something in /etc/init.d managed to panic the machine; it was very
sad.
[13:10:11] <meffie> heh
[13:10:11] <wiesand> the point is, it's late, fairly intrusive, and costs time that would be better spent on 1.8 IMO
[13:11:02] <wiesand> and I'm not going to delay 1.6.23pre1 further for it, at the very least
[13:11:27] <wiesand> it's late enough due to my fault already
[13:11:30] <meffie> agreed, i dont think this should block 1.6.23
[13:12:25] <meffie> this == dcache-panic-rocache
[13:13:09] <wiesand> ok
[13:13:33] <wiesand> I'm afraid that's about what I had to talk about re 1.6 today
[13:13:43] <meffie> but i feel it could be a candidate for a future 1.6.x release
[13:14:37] <wiesand> I feel I may require proof that it can never ever cause problems on a system that basically works but is just overloaded.
[13:15:05] <wiesand> I'm generally weary about those changes.
[13:15:32] <meffie> understood
[13:15:40] <wiesand> They remind me of client side idledead.
[13:16:21] <wiesand> That was supposed to make clients cope when a fileserver is wedged, for example due to a broken vice fs.
[13:16:23] <meffie> heh, yes, we want to avoid that
[13:17:10] <wiesand> What it did was just the opposite, and worse, when writing to a busy but perfectly working server.
[13:18:24] <wiesand> I have similar fears regarding stuff like the just-merged 13033 & company
[13:18:24] Marcio Barbosa leaves the room
[13:19:24] <wiesand> Has it been verified that those have no ill effects on a client under heavy load?
[13:19:39] mvita joins the room
[13:20:18] <mvita> sorry for my lateness - I had something else I needed to finish first.
[13:20:33] Marcio Barbosa joins the room
[13:20:51] <meffie> good morning mark
[13:20:57] <kaduk@jabber.openafs.org/barnowl> Hi Mark
[13:21:22] <wiesand> Hello Mark (& welcome back Marcio)
[13:21:57] <kaduk@jabber.openafs.org/barnowl> Now that you mention it, maybe inspecting (afs_discardDCList ==
NULLIDX && afs_freeDCList == NULLIDX) without the xdcache lock is not
such a good idea
[13:22:02] <Marcio Barbosa> sorry, my connection is not very good today. hi!
[13:22:50] <mvita> EEG - yes, locks are your friends
[13:23:06] <mvita> flout them at your peril
[13:23:15] <kaduk@jabber.openafs.org/barnowl> Anyone want to prep a revert on 1.8.x so we have something ready so as
to not delay 1.8.1?
[13:23:34] <meffie> 13033, oh, yes, the site that uses that patch runs the clients on heavy loads
[13:23:50] <mvita> re: load testing
[13:23:56] <kaduk@jabber.openafs.org/barnowl> In other news, apparently the windows buildbot rules will happily mark
as succeeded a build where we try to export a symbol from a library
that doesn't have a definition in that library.
[13:24:47] <wiesand> what should be reverted? the getdslot-eintr topic?
[13:25:37] <kaduk@jabber.openafs.org/barnowl> "afs: Avoid GetDCache panic on AllocDCache failure" I think does not
need to be reverted, but the other two in that topic
[13:26:20] <mvita> sorry I came in late - was there a report of a problem?
[13:26:20] Marcio Barbosa leaves the room
[13:27:01] <kaduk@jabber.openafs.org/barnowl> Stephan is exercising justified skepticism, and I (maybe) found a bug
as a result
[13:27:34] <kaduk@jabber.openafs.org/barnowl> But no concrete problem report other than source code inspection
[13:27:35] <wiesand> I hate it when I'm right about such things :-(
[13:27:47] <meffie> lol
[13:27:59] <mvita> <door, brb>
[13:28:24] Marcio Barbosa joins the room
[13:28:42] <wiesand> I can prepare the revert of 1319{0,1}
[13:29:08] <wiesand> 1.8-only?
[13:29:15] <meffie> should we just do patch to fix them? what is the issue?
[13:29:26] <kaduk@jabber.openafs.org/barnowl> okay, thanks.  (Possibly only 13190 needs the revert, but for
path-conflict-avoidance both seems better.)  Yeah, 1.8-only; master
should just get a direct fix.
[13:30:15] <kaduk@jabber.openafs.org/barnowl> Mike: yes, we should do the patch to fix them, but I would rather
revert than have waiting for the patch hold up 1.8.1
[13:31:10] <kaduk@jabber.openafs.org/barnowl> And the issue is that we are now looking at afs_discardDCList and
afs_freeDCList while not holding the xdcache lock
[13:31:58] <kaduk@jabber.openafs.org/barnowl> which sure looks like it should be a requirement, even if it's not
explicitly documented that I've found yet
[13:32:00] <mvita> back
[13:32:07] <meffie> because the lock is released on line 1974?
[13:32:38] <kaduk@jabber.openafs.org/barnowl> yeah
[13:33:03] <kaduk@jabber.openafs.org/barnowl> In the old code, that was fine, since downDCount is local to the
current function
[13:34:49] <meffie> ok, good catch
[13:35:04] <kaduk@jabber.openafs.org/barnowl> Yes, thanks wiesand!
[13:35:43] <kaduk@jabber.openafs.org/barnowl> Oh, hah, I haven't actually merged 13191 on 1.8 yet, so just revert
13190 :)
[13:36:02] <wiesand> yes, just noticed too
[13:36:15] <kaduk@jabber.openafs.org/barnowl> "but I can probably move on to looking at a different change instead
of finishing that one"
[13:44:17] <wiesand> revert is 13217
[13:44:30] <meffie> 13211 could use your attention Ben :)
[13:46:32] <wiesand> 13211 looks correct to me, but I'm not sure I understand the problem
[13:46:44] <meffie> ah, the original code did...
[13:47:14] <meffie>     ubik_dprint("some message %d", code = ERROR_NUMBER);
[13:47:28] <meffie> note the '=' is an assignment
[13:47:33] <kaduk@jabber.openafs.org/barnowl> I ... don't remember why I pushed +2 and then not "submit".
[13:48:12] <mvita> an assign minefield
[13:48:20] <meffie> ubik_dprint was a function, and so the assignment to `code` was done as a side effect
[13:48:20] <kaduk@jabber.openafs.org/barnowl> The only thing that comes to mind is to ensure that we discussed it
today, but the ViceLog change is not merged on 1.8 yet
[13:48:59] <wiesand> I'll pull up 13153 on top of that ;-)
[13:49:27] <meffie> when i replaced the function calls with macros, the assignment may not happen, depending on the current LogLevel
[13:49:29] <wiesand> Ah, Andrew's comment makes it clear. Sorry for being dumb.
[13:50:06] <kaduk@jabber.openafs.org/barnowl> I guess we could confirm that all the other ubik changes currently
staged for 1.8 are after the ViceLog conversion and we don't feel a
need to reorder them to get anything in sooner than the ViceLog
conversion.
[13:50:37] <meffie> this should have been fixed *before* i converted the functions to macros. sorry.
[13:51:06] <meffie> i didnt know the original developers were out to get me.
[13:51:29] <kaduk@jabber.openafs.org/barnowl> Yeah, they were real sneaky meanies, or something.
[13:51:38] <meffie> exactly. :)
[13:51:51] <meffie> clever c programmers
[13:53:29] <wiesand> 13186 would need a rebase
[13:55:16] <wiesand> but that's the only one with a path conflict
[13:55:24] <mvita> btw, how was the lock issue discovered?  By inspection, or was a problem reported?
[13:56:01] <mvita> because it is wrong, but I'm not seeing how it would cause problems
[13:56:31] <wiesand> inspection, by Ben
[13:56:32] <kaduk@jabber.openafs.org/barnowl> inspection
[13:57:37] <mvita> I complement your eagle eye, sir.
[13:57:52] <mvita> s/complement/compliment/
[14:01:53] <mvita> dropping for another mtg…
[14:02:03] <kaduk@jabber.openafs.org/barnowl> *waves*
[14:02:10] <wiesand> Ben, do you want 13211 based directly on 13153, or is 13186 sufficiently trivial?
[14:02:32] <meffie> oh, i better start that other meeting...
[14:03:14] <kaduk@jabber.openafs.org/barnowl> 13186 is sufficiently trivial
[14:04:28] <meffie> mark is talking to andrew now about this
[14:05:58] <kaduk@jabber.openafs.org/barnowl> If you are dropping off for another meeting, should we declare this
one done?
[14:07:13] <wiesand> 13211 pullup is 13218, to be merged after 13153 and 13186
[14:07:50] <wiesand> But yes, let's declare this meeting finished?
[14:08:18] <kaduk@jabber.openafs.org/barnowl> Sounds like a plan.
[14:08:36] <kaduk@jabber.openafs.org/barnowl> (I did look at rxgk a little bit and Andrew is going to make an
updated version of the configure changes.)
[14:08:58] <kaduk@jabber.openafs.org/barnowl> Thanks everybody!
[14:09:01] <wiesand> Thanks a lot everyone! Have a nice weekend.
[14:09:36] <kaduk@jabber.openafs.org/barnowl> You too (re nice weekend)
[14:10:30] <meffie> oh, wiesand, joe is talking to linux upstream about changes that break us for 4.18
[14:11:14] <wiesand> ah, good
[14:11:39] <wiesand> good thing we still have that 1_6_22_branch too
[14:17:55] <meffie> have a good weekend, i'll try to send out notes in a timely manner.
[14:17:58] meffie leaves the room
[14:19:26] <kaduk@jabber.openafs.org/barnowl> Thanks again for doing the notes
[14:21:40] wiesand leaves the room
[14:47:29] Marcio Barbosa leaves the room
[14:49:34] Marcio Barbosa joins the room
[15:00:49] mvita leaves the room
[15:20:27] mvita joins the room
[16:15:57] Marcio Barbosa leaves the room
[16:18:15] Marcio Barbosa joins the room
[16:46:14] mvita leaves the room
[16:47:28] mvita joins the room
[19:46:26] Marcio Barbosa leaves the room
[19:48:35] Marcio Barbosa joins the room
[20:37:41] mvita leaves the room
[20:47:43] mvita joins the room
[21:16:52] Marcio Barbosa leaves the room
[23:49:44] mvita leaves the room