- Thursday, March 10, 2016

openafs@conference.openafs.org

Thursday, March 10, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[01:57:53] mvita leaves the room
[01:59:03] mvita joins the room
[03:00:23] mvita leaves the room
[04:57:33] kaduk joins the room
[09:04:02] Simon Wilkinson joins the room
[09:35:32] Simon Wilkinson leaves the room
[09:35:32] Simon Wilkinson joins the room
[09:35:32] Simon Wilkinson leaves the room
[09:36:00] Simon Wilkinson joins the room
[09:37:12] Simon Wilkinson leaves the room
[09:44:05] Simon Wilkinson joins the room
[09:44:15] Simon Wilkinson leaves the room
[11:48:14] Marcio Barbosa joins the room
[11:53:31] Simon Wilkinson joins the room
[12:02:38] Simon Wilkinson joins the room
[12:30:22] Simon Wilkinson leaves the room
[13:04:50] Simon Wilkinson joins the room
[13:20:45] meffie joins the room
[13:56:53] Simon Wilkinson leaves the room
[14:18:12] dwbotsch joins the room
[14:24:30] ballbery@SINENOMINE.NET joins the room
[15:30:00] dwbotsch leaves the room
[15:30:14] mvita joins the room
[15:31:00] dwbotsch joins the room
[16:00:40] kaduk leaves the room
[16:48:24] Simon Wilkinson joins the room
[16:51:20] kadukoafs@gmail.com/barnowlE5725D0E leaves the room
[16:51:27] kadukoafs@gmail.com/barnowlE5725D0E joins the room
[17:09:19] dwbotsch leaves the room
[17:10:14] dwbotsch joins the room
[17:20:46] Simon Wilkinson leaves the room
[18:16:10] Simon Wilkinson joins the room
[18:34:43] meffie leaves the room
[18:40:42] Simon Wilkinson leaves the room
[18:45:17] Simon Wilkinson joins the room
[18:45:29] Simon Wilkinson joins the room
[18:45:34] Simon Wilkinson leaves the room
[18:49:34] Simon Wilkinson leaves the room
[20:12:50] <dwbotsch> if in one of the affected code paths down in osi_fetchstore, if -ERESTARTSYS comes up, what does AFS want to do? Does it want to say, ok, this is restartable, and restart things? Does it want to just return -EINTR at that point? Does it want to bubble up the -ERESTARTSYS and make a decision at some higher level?
[20:12:50] Simon Wilkinson leaves the room
[20:15:11] <jhutz@jis.mit.edu/owl> You certainly can't just return EINTR all they way up to user mode on a
non-interruptible system call.
[20:17:04] <dwbotsch> ok, so, at some point, then, one needs to restart the syscall
[20:18:47] <mvita> but if it was a non-interruptible system call, I think Linux would give you ERESTARTNOINTR instead of ERESTARTSYS
[20:19:12] <mvita> the call in question here (close) is interruptible
[20:21:11] <dwbotsch> is close() ( or afs_close ) the top level syscall (haven't traced the code up that far) ?
[20:21:28] <mvita> I think so, at least in the cases I've duplicated.
[20:21:45] <mvita> but it's actually because AFS does write on close.
[20:21:58] <mvita> we are indeed in close()
[20:22:00] <dwbotsch> well, or sync, right?
[20:22:07] <mvita> but it's the write that's being interrupted
[20:22:22] <mvita> yes, I think fsync() too
[20:22:30] <mvita> but I haven't seen that one myself
[20:22:51] <mvita> any call that would cause openafs to want to write.
[20:23:05] <dwbotsch> mm hmm
[20:25:34] <mvita> this is all new to me in the last week or two, so take all of the above with a large grain of salt - it's just my own current limited understanding
[20:25:42] <dwbotsch> right
[20:26:00] <jhutz@jis.mit.edu/owl> Yeah, so that could include write.
Also, while it might be OK to return an error from close, it's really not
OK for AFS to _give up writing the data back_ and return an error on close.
[20:26:20] <mvita> well - that's the trick - AFS may have written "some" data
[20:27:08] <mvita> ERESTARTSYS can happen any time - at the beginning (before any bytes have been written), at the end (after all have been written) or any time in between
[20:28:14] <mvita> that's really why linux gives us ERESTARSYS - only the filesystem can know what actions should be taken to "restart" the current syscll
[20:28:57] <mvita> syscall
[20:29:01] <dwbotsch> so, I'm wondering if one could, for example, in osi_fetchstore.c - afs_linux_storeproc around the code = sendfile(), put a while loop... if ERESTARTSYS, just call back again
[20:30:00] <dwbotsch> right, so, you get an ERESTARTSYS and either decide to go do something else then come back, just go back, or give up (EINTR)
[20:31:41] <dwbotsch> it's unclear what is wanted
[20:31:48] <mvita> ^^
[20:31:49] <dwbotsch> whups, wrong window on that last statement
[20:32:02] <mvita> and yet remarkably appropriate
[20:32:44] <dwbotsch> so, one needs to decide what AFS should do, and if it should do it at the lower level, or go up and handle it at the top level as a return code for afs_linux_fsync / etc
[20:33:07] <mvita> or defer until you finish the current openafs operation and then return EINTR
[20:33:38] <dwbotsch> that's another possibility... save that state, loop, then return -EINTR up the stack
[20:34:07] <mvita> sorry, gotta focus on something else right now.... stepping away
[20:34:25] <dwbotsch> sure
[20:56:45] <ballbery@SINENOMINE.NET> so, we had a discussion about the general idea of long-running syscalls being interruptoible the other day which suggests that maybe we want to do this differently anyway
[20:57:40] <ballbery@SINENOMINE.NET> although I am now wondering about how 'fs storebehind' interacts
[20:58:56] <ballbery@SINENOMINE.NET> anyway ot occurs to me that close() should just return after queueing the server write to a kernel thread. userspace won't get the success/failure but (a) with storebehind on they wouldn't anyway (b) there's not much they could do about it if it did fail (c) the number of programs that check the return of close() is ... tiny
[20:59:57] dwbotsch leaves the room
[20:59:59] <ballbery@SINENOMINE.NET> that said, I'm more an admin type and dont really know that much about what's going on behind the scenes here beyond "it writes back to the server"
[20:59:59] dwbotsch leaves the room
[21:00:01] dwbotsch joins the room
[21:01:43] <ballbery@SINENOMINE.NET> but there are users who (a) expect to be able to interrupt long-running operations (b) do not expect that to mean that a file write into AFS becomes partial
[21:02:17] <dwbotsch> I dunno... if I ctrl-c a file write, should the write be partial, or should my ctrl-c have no effect?
[21:02:59] <ballbery@SINENOMINE.NET> the problem there is that the assumption is that a write at program level maps to a write to the server, whereas with afs it's all done at the close()
[21:04:03] <ballbery@SINENOMINE.NET> we already muck with expectations mostly invisbly, potentially with interruptible/non-restaretd close() it becomes a lot more visible and surprising
[21:04:30] <ballbery@SINENOMINE.NET> (possibly, with storebehind on you just hand off to the storebehind thread, and with it on interrupt would hand the rest of the write to the storebehind thread rather than aborting,
[21:04:47] <ballbery@SINENOMINE.NET> but I don;t know how storebehind currently works...
[21:19:03] <dwbotsch> one could argue that simply replicating the old behavior to the end user is the right answer
[21:21:18] <kadukoafs@gmail.com/barnowlE5725D0E> It is at least hard to argue that it would be wrong to do so, though
perhaps there are better choices if freedom is given to change the
architecture.
[21:22:27] <jhutz@jis.mit.edu/owl> I argue that hiding write failures from programs that bother to check
the result of close or fsync is not a reasonable change for stable.
[21:23:17] <dwbotsch> is afs currently hiding write failures?
[21:28:59] meffie joins the room
[21:32:11] meffie leaves the room
[21:46:47] <jhutz@jis.mit.edu/owl> It tries not to.
[21:47:13] <jhutz@jis.mit.edu/owl> In some cases _Linux_ may hide write failures by not bothering to
propagate errors we return. That's not the same thing.
[21:47:38] Marcio Barbosa leaves the room
[21:57:24] ballbery@SINENOMINE.NET leaves the room
[23:35:20] kaduk joins the room
[23:37:34] mvita leaves the room