- Thursday, June 19, 2014

openafs@conference.openafs.org

Thursday, June 19, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[00:57:19] mvita leaves the room
[00:58:37] mvita joins the room
[02:06:44] mvita leaves the room
[02:12:34] mvita joins the room
[04:07:06] mvita leaves the room
[05:07:05] ktdreyer joins the room
[05:07:44] ballbery leaves the room
[05:09:13] ballbery joins the room
[06:43:48] Jeffrey Altman leaves the room
[07:00:33] Jeffrey Altman joins the room
[09:25:46] ktdreyer joins the room
[14:12:45] mvita joins the room
[14:50:40] wiesand joins the room
[14:52:47] <wiesand> I just evacuated a fileserver. When is it safe to shut it down? (meaning: when will clients stop timing out because they assume a volume lives on that server?)
[14:54:36] <jhutz@jis.mit.edu/owl> Hrm.  The set of cache lifetimes, callbacks, and timeouts involved is
complex, but you shouldn't have to wait more than a couple of hours.
[14:54:53] <wiesand> Thanks!
[15:01:06] <ballbery> aside from that r/w volume caching issue at least
[15:02:00] <jhutz@jis.mit.edu/owl> What "r/w volume caching issue" ?
[15:02:57] <ballbery> where unix cache managers effectively never expire information for an r/w volume with no ro-s (like home dirs)
[15:03:23] <jhutz@jis.mit.edu/owl> I thought we fixed that.
[15:04:10] <ballbery> right, so it depends on what version is running on the relevant clients
[15:09:10] <jhutz@jis.mit.edu/owl> True.  So for old clients, I believe the answer is that if the client is
offline when the volume is moved _and_ doesn't try to access it until the
old server has been shut down, you lose, period.
[15:09:46] <jhutz@jis.mit.edu/owl> If you were online during the move, you'll get a callback break.
Though I suppose that might not help if you have no callbacks.
If the server is still online when you try to access the volume, you'll
get a volume-moved notification.
[15:10:31] <jhutz@jis.mit.edu/owl> At some point we did an in-depth analysis of this.
Hopefully it was in email or on zephyr.
[15:17:29] <ballbery> think it was on -devel. I recall deason being in on it
[15:18:43] <ballbery> (I also recall seeing it in ECE once and being told "that can't happen" at the time (2008ish? no longer have those notes)
[15:20:53] <Jeffrey Altman> VMOVED is only returned on calls that are actively waiting for the volume lock when the move is in progress.   Otherwise, the error is VNOVOL.  The file server doesn't maintain state as to which volumes it had in the past.
[15:30:32] <jhutz@jis.mit.edu/owl> Oh, hm.  I suppose that's true.
Well, you'll get VNOVOL, then, which ought to be sufficient, but I
don't remember if it is.  Really, this worked just fine once upon a time,
then was horribly broken without anyone really understanding that it was.
and hopefully it's been fixed.
[15:30:46] <jhutz@jis.mit.edu/owl> Just don't retire your servers, and you won't have this sort of problem :-)
[15:35:59] <wiesand> And I was afraid it was a stupid question ;-)
[15:35:59] wiesand leaves the room
[15:54:51] ktdreyer leaves the room
[16:08:12] deason joins the room