[00:35:55] --- dev-zero@jabber.org has left [01:11:13] --- dev-zero@jabber.org has become available [01:17:55] --- abo has left [01:27:42] --- dev-zero@jabber.org has left [01:27:52] --- dev-zero@jabber.org has become available [03:04:34] --- Simon Wilkinson has become available [03:04:45] --- Simon Wilkinson has left [04:58:52] --- Jeffrey Altman has become available [05:00:14] --- jaltman has left: Replaced by new connection [05:00:14] --- jaltman has become available [05:15:15] --- kula has become available [06:13:44] --- deason has become available [06:35:07] --- sxw has become available [07:49:54] --- jaltman has left: Disconnected [08:03:09] --- Jeffrey Altman has left [08:43:05] I'll deal with RT 126087 ... [08:44:46] ok, then i won't bother. i had it open :) [08:52:49] Who's looking after rxosd integration now Felix isn't around? [08:53:50] um..... christof, yes? [08:57:00] We should probably ask him to look over Chas's changes. The fetch/storeVariables combination, in particular, in case there's some OSD reason that they had to be the way they were. [08:57:53] agreed. i don't think he's regularly been using jabber alas [09:07:28] --- stevenjenkins has left [09:08:29] --- jaltman has become available [09:11:21] --- stevenjenkins has become available [09:15:00] --- Simon Wilkinson has become available [09:17:15] --- sxw has left [09:19:39] --- dev-zero@jabber.org has left [10:50:27] --- Russ has become available [11:00:19] --- Simon Wilkinson has left [11:25:08] --- Simon Wilkinson has become available [11:25:23] --- Simon Wilkinson has left [11:26:02] --- Simon Wilkinson has become available [11:26:18] Bah, no struct flock64 on some 64bit architectures. Mutter. Mutter. [11:35:18] --- dev-zero@jabber.org has become available [11:40:42] Disregard last - problem is faulty packaging, not our code. [11:45:58] Missing key headers? [11:47:28] Building a 64bit client with a 32bit sysname. [11:48:33] Oh, aha. [11:48:43] (The sysname picks the param set to use, which in turn controls the AFS_LINUX_64BIT_ENV define, which determines whether we use struct flock or struct flock64). I hate the fact that our configuration system tests for some things, and hardcodes others ... [11:58:53] --- dev-zero@jabber.org has left [12:13:49] --- jaltman has left: Disconnected [12:41:30] radio silence from christof so far. i wonder if we already missed him for the day by the time the rxfs stuff went into gerrit. or if he's on holiday [12:48:23] --- dev-zero@jabber.org has become available [12:49:29] It's probably worth waiting a little for him to respond. [12:49:53] sure [12:49:57] I have my concerns about the iovec stuff, anyway. It seems to embed a lot of knowledge about how stuff is allocated without ever really documenting it anywhere. [12:50:03] it's not like we're in a hurry for a 1.5.x release with this [12:50:15] Like, you change the allocator for rxfs_context, and boom. [13:06:17] --- dev-zero@jabber.org has left [14:51:53] --- jhutz@jis.mit.edu/owl has become available [14:52:51] 1f2fccb should probably appear in 1.4.12 [14:56:54] I don't seem to have that object in my repo ... [14:58:42] It's the cherry pick of the noatime fix you pushed to gerrit [14:58:48] Unless I typoed it [14:59:48] 1070 [15:00:30] e34702ef [15:00:49] (you have to use the start of the hash, not the end, if you are abbreviating it) [15:00:49] Oh, oops [15:01:08] I knew that, really :-) [15:01:23] But yeh. My only fear is if doing NOATIME properly exposes some kind of a race. It's awful late for 1.4.12 now. [15:03:10] --- deason has left [15:04:21] I wonder what we collide with [15:05:34] ... Nothing, in 2.6.28 [15:07:35] I'm just checking in git. My suspicion is that MS_NOATIME was so large that we don't collide at all, we just don't achieve anything by setting it [15:07:54] Huh. Also nothing in -next. The largest S_ in is 512 [15:08:06] MS_NOATIME is 1024 [15:08:41] Yeh, we're clear. [15:09:10] I think that means we don't have to have this for 1.4.12 ... [15:09:15] In which case, I take it back; no need for this in .12 [15:09:42] I mean, I want it, but... [15:10:03] did we ever stop touching the CacheItems file every second? [15:10:11] Personally, I don't think it's worth the risk until it's been given some soak testing ... [15:10:26] Sorry. _I_ want it. I don't want it in .12 [15:10:38] Sure. [15:10:50] CacheItems - were we reading every second, or writing every second? [15:11:09] writing [15:11:29] well, touching, anyway [15:12:52] --- stevenjenkins has left [15:15:55] I haven't looked at code, but the evidence from this machine suggests that we are. [15:16:18] --- stevenjenkins has become available [15:25:17] And yes, the touch code in WriteThroughDSlots is still there. Surely we should just touch that file as part of a clean shutdown. Afterall, if we _haven't_ shut down cleanly, the state of the cache is anybody's guess. [15:27:58] ... and it's worse than just touching. We rewrite the header (and on Linux at least, the first 4k page of data) every second. [16:05:31] --- jaltman has become available [16:31:47] --- dev-zero@jabber.org has become available [16:46:04] --- dev-zero@jabber.org has left [16:46:19] --- dev-zero@jabber.org has become available [18:34:38] --- Jeffrey Altman has become available [18:35:08] --- Jeffrey Altman has left [19:15:59] --- Jeffrey Altman has become available [19:16:49] --- Jeffrey Altman has left: Replaced by new connection [19:46:17] --- Jeffrey Altman has become available [19:46:32] --- Jeffrey Altman has left [22:11:58] --- dev-zero@jabber.org has left [22:18:48] --- reuteras has become available [22:57:57] --- Russ has left: Disconnected [23:35:52] --- dev-zero@jabber.org has become available [23:51:32] --- dev-zero@jabber.org has left [23:51:43] --- dev-zero@jabber.org has become available