[00:06:25] --- jaltman has left: Replaced by new connection [00:06:27] --- jaltman has become available [01:14:30] --- dev-zero@jabber.org has become available [01:31:00] --- Jeffrey Altman has become available [01:31:28] --- jaltman has left: Replaced by new connection [01:31:30] --- jaltman has become available [02:55:44] --- jaltman has left: Replaced by new connection [02:55:45] --- jaltman has become available [03:44:36] --- dev-zero@jabber.org has left [04:20:03] --- pod has become available [04:37:57] --- dev-zero@jabber.org has become available [04:58:26] --- dev-zero@jabber.org has left: Replaced by new connection [04:58:27] --- dev-zero@jabber.org has become available [04:58:52] --- dev-zero@jabber.org has left [04:59:03] --- dev-zero@jabber.org has become available [06:40:02] --- dev-zero@jabber.org has left [06:45:42] --- mdionne has become available [06:53:46] gerrit's not responding here - zapping cookies and restarting the browser doesn't help - can someone poke it? [06:58:10] --- Jeffrey Altman has left: Replaced by new connection [06:59:46] --- jaltman has left: Replaced by new connection [06:59:48] --- jaltman has become available [07:05:41] if i can remember what i need to do with remctl [07:10:25] started jetty. hm, weird error from remctl tho [07:10:49] failed. crap [07:13:52] wtf... gerrit's homedir is /var/lib/svn? [07:21:41] ok. apparently i don't get to restart it, because the remctl backend for doing so, well, it doesn't seem to work. so i guess it's down until someone more powerful than me appears [07:25:18] ok, thanks - I'll just be patient. Wanted to push an update to 752, the put_cred is in the wrong place. [07:32:09] which led me to notice that there's a lot of apparently unused code there... [10:05:20] --- dev-zero@jabber.org has become available [10:12:28] --- dev-zero@jabber.org has left: Replaced by new connection [10:12:29] --- dev-zero@jabber.org has become available [10:13:10] --- dev-zero@jabber.org has left [10:13:27] --- dev-zero@jabber.org has become available [10:38:36] --- sxw mobile has become available [10:42:20] I'll fix gerrit just as soon as I find somewhere with WiFi [11:22:42] --- sxw mobile has left [11:39:59] --- dev-zero@jabber.org has left: Replaced by new connection [11:40:00] --- dev-zero@jabber.org has become available [12:05:33] --- jaltman has left: Disconnected [12:46:56] --- mdionne has left [13:10:44] --- haba has left [13:10:48] --- haba has become available [13:14:48] --- sxw mobile has become available [14:55:17] --- dev-zero@jabber.org has left [15:20:22] --- sxw mobile has left [15:40:40] --- Simon Wilkinson has become available [15:40:50] gerrit (finally) restarted [15:42:52] --- mdionne has become available [15:43:19] looking much better! thanks [15:43:54] thank you. mental note: the remctl script doesn't work [15:46:12] Yeh. That'll have to wait for Russ to get back. [15:47:02] On the plus side, I downloading afs_vnop_open.c to my mobile today, and managed to find a nice large race condition in LocalHero. [15:55:16] So, I'm going to scribble this here, in the hope that someone will tell me that I'm wrong, and we can all get on with life as normal. Immediate answers not expected! [15:56:15] LocalHero gets the new DataVersion from the server, and checks that the copy that we've got locally still has a valid callback, and the data chunk is up to date. If so, it updates the local version to have the same dataversion as the one we just received, and we make the changes locally. [15:57:41] But, we never check that our old DataVersion is one less than the one that we've just received. So, if we've missed a callback (due to an overzealous NAT), or if there's a race in callback handling against LocalHero, we might 'skip' a version from the server, and end up with a local version that, despite having the same version number, differs in content from the server's copy. [15:57:47] Or am I missing something? [16:23:28] i remember discussing this before and we concluded we didn't care. i don't remember where, or why. [16:24:45] not zephyr. [16:28:56] not jabber. perhaps an RT i can't see anymore. but it would have been jhutz or chaskiel, i suspect, who came up with why we didn't care. that or i imagined it which is entirely plausible [16:29:09] If you can dig up a pointer, I'd be interested to see it. Because at the moment, I suspect it's the cause of the directory issues I'm seeing. [16:29:50] it may very well be. we should probably fix it since my recollection anyway was not "fixing bad" only "fixing unneeded" [16:29:55] (well, a possible cause - it doesn't tie in with the fact that I think all of the directory updates are coming from one client, which wouldn't cause this) [16:30:00] I'll look at the options. [16:30:52] well, the options for fixing seem pretty simple: either you have N-1, or you can't LocalHero [16:31:54] Yeh. I want to see what the impact of that is though ... [16:33:03] *if* my copy of the file was out of date, refetching may result in something other than what i thought i saved being in my cache. of course, it means my cache won't not match the server. [16:33:53] There doesn't seem to be a downside ... [16:34:30] well, the "ideal" situation is you notice *before* performing the operation, not after [16:34:35] but, life's hard. [16:35:16] I think the only case that this can happen is where there are two directory operations racing the server. And hey, someone's got to win ... [16:35:38] they don't have to race if a callback is dropped [16:37:40] What happens with client A creates, client B starts create, client A completes (and callback is broken). I think we can be in a situation where A's callback break won't be seen until after B has sent its RPC to the server - so you can't see _before_ [16:38:25] My suspicion is that our locking means that it's possible that B will have done LocalHero before it sees A's callback break, but I need to verify that. [18:06:45] --- mdionne has left [18:47:26] --- jaltman has become available