[00:15:49] --- jaltman has left: Disconnected [01:00:12] --- dev-zero@jabber.org has become available [01:00:49] --- dev-zero@jabber.org has left [01:06:29] --- dev-zero@jabber.org has become available [01:09:19] --- haba has left [01:51:49] --- Simon Wilkinson has left [02:23:13] --- andersk@mit.edu/dr-wily has left [03:29:44] --- Simon Wilkinson has become available [03:45:08] --- kaj has become available [03:51:38] --- Simon Wilkinson has left [03:52:15] --- abo has left [03:52:50] --- abo has become available [04:05:19] --- reuteras has left [04:10:57] --- dev-zero@jabber.org has left [04:24:24] --- dev-zero@jabber.org has become available [04:34:58] --- dev-zero@jabber.org has left [04:35:08] --- dev-zero@jabber.org has become available [04:35:28] --- dev-zero@jabber.org has left [04:36:23] --- dev-zero@jabber.org has become available [04:57:28] --- dev-zero@jabber.org has left [04:57:38] --- dev-zero@jabber.org has become available [04:57:58] --- dev-zero@jabber.org has left [04:58:00] --- dev-zero@jabber.org has become available [05:07:11] --- Simon Wilkinson has become available [05:21:03] --- jaltman has become available [05:23:58] --- kaj has left [05:25:58] --- dev-zero@jabber.org has left [05:26:10] --- dev-zero@jabber.org has become available [05:30:28] --- dev-zero@jabber.org has left [05:33:08] --- kaj has become available [05:39:37] --- dev-zero@jabber.org has become available [05:49:38] --- haba has become available [05:59:50] --- Simon Wilkinson has left [06:14:51] --- abo has left [06:15:27] --- abo has become available [06:29:26] --- Simon Wilkinson has become available [06:51:51] --- deason has become available [07:18:09] --- reuteras has become available [07:19:41] --- reuteras has left [07:39:18] --- reuteras has become available [07:39:48] --- reuteras has left [08:10:30] --- Simon Wilkinson has left [08:13:43] --- Jeffrey Altman has become available [08:16:14] we've fixed all the bugs we *need to* fix for the fileserver hostcount issue, that i can tell, yes? i'm going to push one more (client) change to unroll the dropbox thing and issue 1.4.12 rc4, and that hopefully is it. [08:22:46] --- Claudio Bisegni has become available [08:23:16] --- Claudio Bisegni has left [08:25:12] 1367 and 1368 are related; I suppose those aren't *need to* fixes... I mean, they're safety checks [09:09:58] --- abo has left [09:10:51] --- abo has become available [09:22:37] --- kaj has left [09:26:46] --- haba has left [09:40:09] --- meffie has become available [10:04:49] --- andersk@mit.edu/dr-wily has become available [10:09:22] --- Kevin Sumner has become available [10:09:27] --- Simon Wilkinson has become available [10:09:51] --- Simon Wilkinson has left [10:10:11] --- Simon Wilkinson has become available [10:22:23] --- Kevin Sumner has left [10:47:46] --- Claudio Bisegni has become available [10:48:08] --- Claudio Bisegni has left [10:51:36] --- dev-zero@jabber.org has left [11:09:11] Well, that's Pandora's box fully opened ... [11:30:10] --- kaj has become available [12:09:27] ? [12:21:01] afs3-stds [12:35:14] I've sort of considered this issue before. I really wanted the assigned numbers registry to publish .xg files that ~anyone could use. But never badly enough to spend time doing anything about it. [12:35:37] jaltman's answer may be the best -- get IBM to formally release the .xg files so we can use them [12:39:23] --- kaj has left [12:42:13] --- kaj has become available [13:13:51] --- Russ has become available [13:16:20] --- Russ has left: Disconnected [13:17:37] --- Russ has become available [13:22:02] --- Simon Wilkinson has left [13:25:57] --- Simon Wilkinson has become available [13:42:25] --- jaltman has left: Disconnected [13:55:29] --- Russ has left: Disconnected [14:22:21] --- Russ has become available [14:55:36] --- meffie has left [15:13:18] I'm unclear on the difficulties of PAGs in OSX; why do we not intercept setgroups(2) like we do other places we don't have an otherwise usable way to create PAGs? [15:15:12] Intercepting setgroups() requires you to be able to patch the syscall table [15:17:11] and OSX prevents that? [15:19:06] OSX prevents kernel modules from doing most things that aren't explicitly permitted by the KPI. [15:20:22] --- abo has left [15:20:25] For different levels of "prevents" depending on how new your OSX is [15:20:42] can't hook syscall table [15:20:47] Note that setgroups() isn't our fallback position. It's our starting point. The only reason that we started using keyrings on Linux is because they broke our ability to patch setgroups(). [15:21:07] --- abo has become available [15:21:26] and yes, since 10.4, you simply can't modify syscall table [15:21:54] prior to that, pags existed but because of how loginwindow works weren;t useful [15:22:02] (you are not a child of loginwindow) [15:23:17] there's a lot of backstory i didn't put in the ticket including 2 exhaustive discussions with people who i expected to have better ideas than me. they didn't. [15:24:04] ticket? [15:24:07] I'll shut up after one more uninformed idea: if NOTE_FORK doesn't work, can't you get the same information from dtrace? [15:24:10] Should I go read port-darwin? [15:24:14] read port-darwin's last post [15:24:20] 123563 is the ticket, though [15:24:44] dtrace has the same racy issue [15:26:09] also, we'd have to trace every process, which i presume would have some overhead [15:27:51] >dtrace ew ew ew ew ew [15:27:58] it wouldn't be a 'trace proc X' for every proc in the system, you'd be tracing the fork syscall or some kernel function maybe further down.... but if you just mean tracing all the forks for everything, yeah, no matter how you do that I'd imagine overhead [15:28:23] Before I post it to the mailing list, I'd be interested in any comments people have on /afs/cs.cmu.edu/user/jhutz/tmp/fs-perf-tuning [15:28:55] I don't think you'd trace fork. Presumably you'd trace setgroups. But still ew [15:29:03] you have to trace every fork of a process which is enrolled in a pag. if there are races that may mean you need to trace every fork [15:29:23] basically, i am not doing anything further with dtrace. [15:30:07] You could solve 90% of the the problem by tracking processes and their parents. But it means that a process can escape from a PAG if it becomes owned by init. [15:32:09] in any case, i assume you get what i mean about "any possible solution is really really bad" [15:32:25] even the directory services plugin isn't pleasant [15:33:27] yes, I wasn't imagining any of that would work, just was curious why it wouldn't [15:34:11] well, i could do several things which are either flaky or likely to be yanked from under me. i need to look at directory services more tho [15:35:49] jhutz: That looks good. If you're going to mail it to one of the OpenAFS lists (and I hope you do), it's probably worth noting that 'we' refers to your current usage, and not to the fileserver's current defaults. [15:36:32] the rationale and computations all look ok [15:36:58] Yeah; it'll get some cleanup and whatnot before posting. Actually, "we" refers to the settings I'm about to apply. Our current settings _are_ the defaults. :-( [15:38:11] --- deason has left [15:43:51] At some point, I'd like to substantially rework the dir package. In fact, I was 90% of the way through doing so, but now I can't find the code ... [15:44:42] honestly, with the current directory format, I think buffering individual directory pages instead of whole directories is silly. [15:45:17] I got something working on Linux where we at least used the page cache in the kernel, rather than our own dir cache. [15:45:40] It wasn't in the 1980's, but it is now. [15:46:20] Well, that's the other thing -- we probably want to separate fileserver and CM implementations of directories fairly soon. [15:46:40] We really want a directory lookup RPC. [15:47:06] Matt presented something at Edinburgh, but it hit the Unicode wall. [15:47:47] We have one, and it would be trivial to implement, but I'm not sure that's actually what we want. For one thing, part of what I learned in this tuning research process is that directory buffer handling on the fileserver is sort of dependent on the idea that the fs is not involved in every lookup. [15:48:27] So, I actually kind of like jaltman's model of reading a directory, converting it into a suitable b-tree, and then continuing to handle normalization- and, where appropriate, case-independent lookups locally. [15:48:52] I like that model too. It also works for disconnected mode. [15:48:59] To do that, the CM's directory implementation would completely change, and all it would need is a way to parse the old dir format and whatever new wire protocol we come up with. [15:49:25] Whereas the fileserver would need to _produce_ the old format and whatever the new wire protocol is, and it's not clear that either of those should be the fs's representation long-term. [15:49:38] --- abo has left [15:50:03] Yes. You also don't want to tie the fileserver to a particular representation - different fileservers will store dirs in different ways. [15:50:04] --- abo has become available [15:50:50] The long-term representation should be efficient to maintain and to convert to the old and new wire formats. The new wire format should be efficient for _exchange_, with the knowledge that clients more or less have to parse it as they receive it, since what they do will depend on local normaliztation tables, whether they need case-insensitive lookups, and what local non-unicode 8-bit charsets are in use [15:51:54] If it happened that the needs of openafs's fileserver and the needs of the exchange format were sufficiently compatible, I'd have no problem with using the same representation for both. But that shouldn't be a design goal. [15:51:58] You also need to decide how you're going to represent extended attributes and multiple streams per name. [15:52:31] Well, especially, to what extent those are represented as part of the directory rather than as part of the (abstract) referenced vnode [15:52:50] Yes. Whether you have a single vnode per directory name, or a vnode per stream. [15:53:14] I think they are really part of the vnode, because if you rename a vnode or have multiple links to it, the streams and XA's stay together, rather than being tied to the name. [15:53:53] True. But I kinda like the implementation simplicity of having each stream be an individual FID. [15:54:16] but one possible implementation is for the directory entry to point to an "abstract" vnode, which has among its properties the FIDS of the "concrete" vnodes containing its streams. [15:54:46] That's an interesting idea. [15:55:08] In fact, now that I think about it, that has interesting possibilities, such as allowing different streams for the same file to be in different volumes. Though actually providing that on the server might be too anooying to bother with. [15:55:41] It might make detecting inconsistencies a bit of a pain. [15:55:42] anyway, I need to get going. [15:55:45] Okay. [15:56:05] --- abo has left [15:56:50] --- abo has become available [16:57:16] --- mdionne has become available [17:49:22] --- jaltman has become available [18:56:35] I like the idea of the directory entry pointing to an abstract vnode [18:56:50] I too want to be able to treat alternate data streams as FIDs [19:01:32] Actually, as a refinement I think we want the "abstract vnode" to be the same as the "concrete" vnode for the primary FID. Thus, primary files work exactly as today, and additional streams are attached as extra streams. [19:01:38] --- pod has left [19:11:16] guess i should read backwards, i was thinking about this issue today [19:37:33] --- mdionne has left [21:23:19] --- Jeffrey Altman has left [21:24:35] --- Jeffrey Altman has become available [22:12:42] --- Russ has left: Disconnected [22:23:12] --- reuteras has become available [23:09:18] --- haba has become available [23:29:04] --- kaj has left [23:40:04] --- summatusmentis has left