[00:32:51] --- dev-zero@jabber.org has left [01:20:26] --- dev-zero@jabber.org has become available [01:37:35] --- haba has become available [01:52:19] --- haba has left [02:55:01] --- haba has become available [04:51:52] --- Simon Wilkinson has left [04:54:32] --- Simon Wilkinson has become available [06:56:46] --- reuteras has left [07:16:35] --- deason has become available [07:29:50] --- meffie has become available [07:56:14] --- Simon Wilkinson has left [07:57:42] --- Simon Wilkinson has become available [07:57:44] --- Simon Wilkinson has left [07:58:16] --- Simon Wilkinson has become available [08:05:44] --- stevenjenkins has left [08:11:24] --- stevenjenkins has become available [09:01:01] The new version of bugzilla now has an integrated migration tool ... [09:15:11] --- Russ has become available [09:16:19] --- haba has left [10:07:15] --- dev-zero@jabber.org has left [10:29:43] what does it migrate? [10:33:34] Only GNATS in 3.5.1, but there's folk working on RT. [10:34:29] oh. not what i was thinking [10:35:00] What were you thinking? [10:36:47] --- Simon Wilkinson has left [10:36:52] --- meffie has left [10:42:58] --- Simon Wilkinson has become available [10:43:00] --- Russ has left: Disconnected [10:51:12] --- dev-zero@jabber.org has become available [10:56:41] --- meffie has become available [11:07:08] --- haba has become available [11:17:52] Once OSF_ENV is gone, should we also remove the USE_BUFFERS code (as it's only OSF that uses it), and the iNSTRUMENT_LOCKS definitions (as only OSF ever disabled that) ? [11:18:35] USE_BUFFERS: we might care but i suppose it's in the history [11:19:22] INSTRUMENT_LOCKS: should we ... see what the performance impact is and analyze what we should do with the rest of the code? otherwise, no reason to keep it [11:20:20] I'm tempted to keep USE_BUFFERS until Rainer's code has merged. He uses some of the USE_BUFFERS code to handle working out which block a given DRelease corresponds to. [11:20:42] That is, if we're happy with a linear search every time we release a buffer... [11:22:16] well, we can refactor to avoid that later... [11:36:06] --- meffie has left [12:13:44] I thought we'd fixed Linux so attempts to do -setpag just error out, rather than failing in quiet and wierd ways [12:15:11] that sounds familiar but i see no evidence [12:16:00] The perverse thing is that I think some of David's latest work _will_ actually let us change a parent's keyring. [12:16:28] I'm not sure if we're allowed to acquire the locks necessary to do so, but it is now theoretically possible. [12:16:31] does -setpag have a legit use case? besides an existing interface [12:17:23] aside from the obvious benefit of not needing a subshell and prpahning the parent outside a pag, if you need the parent, no [12:17:42] Just because we _can_ doesn't mean we _should_ [12:18:52] --- haba has left [12:18:53] I meant more in a "we need -setpag or X cannot work" way [12:22:29] --- haba has become available [12:22:29] The big advantage was in just being able to fork a helper program to deal with everything AFS related. [12:22:51] Without -setpag, login (or your PAM module) needs to know how to deal with putting you into a PAG [12:23:17] ... or it has to wrap your shell in pagsh [12:25:09] I'd be quite glad if we just threw -setpag away. [12:26:21] I just wonder if deprecating it, and having aklog yell at you if you use it (even if it works) would be too annoying [12:26:34] I'm not sure that we can do so in the middle of 1.4 [12:26:39] We really should. It's contrary to the UNIX model that assumes you can't change the execution environment of your parent, and that has all sorts of security implications. [12:27:05] Simon: sure, I didn't mean right this instant [12:27:19] But I wonder if I should put in a patch to just remove the 'change parent' option to setpag in the 1.5 tree. [12:28:04] well, I'd say at least mention something to the effect that we recognize it, but don't support it anymore [12:28:30] Well, the kernel would just return EINVAL. [12:28:43] It's up to userspace what it does with that information :) [12:28:51] oh, okay, yeah, I see [12:29:06] read that wrong; I thought you meant just removing the option from aklog [12:29:48] It's not having the option in aklog that causes us the pain. It's supporting it in the kernel that's the fun part. [12:30:00] And I'm in "blowing code away" mode at the moment :) [12:34:31] --- meffie has become available [13:06:54] --- haba has left [13:59:07] Hmmm. Dynamic vcaches also break disconnected, I think. You get 5 minutes with all of your files, then we'll start throwing them away if they're not dirty. [13:59:38] oops? [14:02:10] It'll also completely invalidate the dcache for all AFS entries every 5 minutes too. I'm amazed users aren't moaning about the performance hit. [14:05:57] What is this "dynamic vcaches" thing of which you speak? [14:06:20] It's the code that went in 1.4 to deal with the inotify problem on Linux [14:06:39] Instead of having a hard limit on the number of vcaches, we dynamically allocate more as required [14:07:59] The problem isn't the dynamic allocation, it's that it moves the 'try to free up a vcache' stuff that used to only be called when we were out of options, to being called every 5 minutes from the Daemon thread. [14:08:46] When did this go in? [14:08:57] 1.4.10, IIRC. Hang on. [14:10:33] STABLE14-dynamic-vcache-allocation-20090319 is the delta [14:12:04] Yeh - first release with it in was 1.4.10 [14:13:52] Well, that explains a lot. [14:14:12] ? [14:27:27] I think we need to change things so that we only try to free vcaches if we're only over a high watermark, and then we free ones which are only in the VLRUQ in preference to those that are held in dentries. [14:27:52] I'm in the middle of completely refactoring the vcache code for 1.5 - I can do that there quite easily. I need to think about how to fix this safely for 1.4 [14:52:01] --- mdionne has become available [15:05:09] in kernel 2.6.32 David Howells introduced the KEYCTL_SESSION_TO_PARENT syscall, specifically to support the -setpag functionality [15:05:10] can tkieser and deason be added to 125596. [15:10:19] and since commit 48589b5, aklog -setpag works again with kernel 2.6.32+ [15:12:38] Simon: if you want to glance at 125596, it appears to be related to vcaches, but not to ShakeLooseVCaches (since solaris) [15:12:49] I can add a couple more notes once I'm on the ticket [15:16:00] --- deason has left [16:11:51] --- dev-zero@jabber.org has left: Replaced by new connection [16:11:52] --- dev-zero@jabber.org has become available [16:22:25] --- deason has become available [16:27:26] --- dev-zero@jabber.org has left: Lost connection [16:46:09] --- dev-zero@jabber.org has become available [17:26:35] --- Russ has become available [17:59:13] --- deason has left [18:48:22] --- pod has left [19:08:53] --- mdionne has left [20:23:15] --- deason has become available [20:43:05] --- summatusmentis has left [21:12:59] --- Simon Wilkinson has left: Lost connection [21:45:52] --- deason has left [22:01:47] --- reuteras has become available [23:04:49] --- kula has left [23:51:41] --- haba has become available