[00:15:15] --- jaltman has left: Disconnected [00:28:29] --- haba has left [00:35:47] --- Rasmus Kaj has become available [00:52:58] --- Simon Wilkinson has left [00:55:51] --- Jeffrey Altman has left [00:57:43] --- dev-zero@jabber.org has left [01:36:33] --- Simon Wilkinson has become available [01:44:37] --- dev-zero@jabber.org has become available [02:06:20] --- abo has left [02:06:57] --- abo has become available [02:45:23] --- Russ has left: Disconnected [03:27:38] --- haba has become available [03:36:27] Okay, so after several hours of wrestling with RHEL's RPM to make it understand Fedora's new compression format, we've now got builds in progress for Fedora 12. [03:40:12] Yay! [04:02:10] --- Simon Wilkinson has left [05:07:59] --- reuteras has left [06:13:36] --- Jeffrey Altman has become available [06:13:45] --- jaltman has become available [06:13:56] --- Jeffrey Altman has left [06:33:24] --- Simon Wilkinson has become available [06:53:19] --- Jeffrey Altman has become available [07:03:39] --- deason has become available [07:17:37] --- meffie has become available [07:30:28] --- jaltman has left: Replaced by new connection [07:30:30] --- jaltman has become available [08:19:59] --- dev-zero@jabber.org has left: Lost connection [08:27:19] --- dev-zero@jabber.org has become available [08:42:14] --- meffie has left [09:38:23] --- haba has left [09:58:26] --- Rasmus Kaj has left [09:59:34] --- dev-zero@jabber.org has left [11:49:41] --- Russ has become available [13:22:51] --- haba has become available [13:52:38] If anyone has got a spare moment, it would be worth looking at  git://git.infradead.org/users/eparis/vfsima.git master and seeing if the patches there (which fix the IMA problem) are likely to cause us any further pain. [13:52:48] I would, but I'm up to my eyes in tax at the moment. [13:58:45] in maybe a half hour the tree will finish cloning [13:58:53] i'm actually only slightly kidding [13:59:07] Yeh. It's a complete git tree. [13:59:14] ... of the Linux kernel. [13:59:28] What you're interested in is the difference between that tree and Linus's master. [14:02:20] --- Rasmus Kaj has become available [14:03:20] --- Rasmus Kaj has left [14:15:45] ow [14:16:06] This is one of the downsides of git. to get anything you have to spend time copying way more history than you care about [14:16:22] Yes. [14:17:00] Although, if you already have Linus's tree, and you fetch someone else's, you'll only get the objects that are only in the new tree - you won't copy the whole thing again. [14:24:43] never ate lunch, gonna get dinner. i have a diff up for review then [14:30:55] you can also shallow clone, to only get the N bits of history [14:31:25] Shallow clones can be exciting though - they're not entirely stable, or easy to predict. [14:35:31] --- mdionne has become available [14:45:57] I'll be testing a current mainline kernel with those patches shortly [14:46:41] Cool. Thanks! [14:49:32] --- mdionne has left [15:12:10] --- mdionne has become available [15:15:27] modulo a) minor build breakage in Linus' tree and b) minor 2.6.33 sysctl changes we'll have to adapt to, no problem with that patch set. oh and no more IMA messages [15:15:53] Excellent - that's good news. Hopefully Eric can get it pulled. [15:17:40] Sounds like we might see it for 2.6.33. We"ll then have to see if it gets into stable, and/or if Eric can include it in current Fedora kernels [15:18:32] It's what the RHEL6 kernel looks like that concerns me more than Fedora, really. [15:19:47] Is that currently in beta? [15:20:30] It's all rather quiet on the RHEL6 front at present. [15:20:58] Public beta is supposed to be 'first half of next year'. [15:21:20] What kernel would they be targeting? I don't think IMA has been in the kernel all that long [15:22:49] I don't know which kernel they'll target. The noises I'm hearing is that it will probably look a lot like Fedora 12, with some bits held back, and some bits pulled in from stuff that'll be in Fedora 13. [15:24:12] What that means for the kernel is anyone's guess though. I just know from bitter experience that once the a RHEL has shipped, getting kernel changes is really. really tricky. [15:24:21] rumors used to talk about fedora 9 (2.6.25), but I guess time has passed since then [15:25:37] Lots of the features (NFSv4 by default, for example) that are on the RHEL6 roadmap have only started to appear in Fedora - so I suspect they'll have to go with something more recent than 2.6.25, unless they've already started backporting. [15:26:16] i guess we'll have to make sure to test early and often once alpha/beta versions appear - probably a better chance to get things to change at that point [15:26:52] Yes. I think that would be a very good plan. And to find some enterprise customers who can open issues for us. [15:29:10] mdionne: Did you get a chance to try out splice_read, btw? Do you notice any performance improvement? [15:29:16] i also wonder if the fedora kernel maintainers are also involved in RHEL (i would think so) [15:29:35] I think it's the same group of people. [15:30:53] so if they're aware of some issues (like this one), there's a better chance they'll try to avoid them in RHEL [15:31:12] Hopefully, yes. [15:32:20] I've compiled and ran basic tests with the splice read - it runs OK, but I haven't done performance tests [15:32:52] any differences from the previous version that I tested a while ago? [15:32:54] It is faster, but with RHEL5, I need a very idle fileserver to actually see the speed improvement. [15:33:18] No difference, other than the configure test. [15:34:53] I'll try to run some more tests tonight [15:36:43] My eventual hope is that the RX API can change so it can be passed pages, too, so that when we're not doing encryption, we can have a practically-zero copy code path for reads. [15:38:19] s/reads/stores/ [15:48:25] --- deason has left [15:53:29] any particular type of workload where you would expect this to make more of a difference? - i'm running some large compiles and seeing pretty much the usual timings [16:19:56] --- mdionne has left [16:29:15] Simon: do you have an idea of what you want the API to look like? The Windows code is already using the iovec interface to send all data stores. What it does is pass in pointers to the extent buffers with appropriate lengths. [16:30:01] what I don't have at the moment is an iovec read mechanism that can read directly into the extent buffers but that shouldn't be all that hard to do [16:31:18] --- jaltman has left: Disconnected [17:05:22] --- Derrick Brashear has become available [17:56:37] --- jaltman has become available [18:05:32] --- dev-zero@jabber.org has become available [19:03:34] --- deason has become available [19:09:33] --- shadow@gmail.com/owl0AF8D343 has left [20:08:45] --- kula has left [20:21:32] --- kula has become available [22:15:40] --- reuteras has become available [22:25:44] --- deason has left [22:38:47] --- dev-zero@jabber.org has left [22:39:00] --- dev-zero@jabber.org has become available [23:41:34] Pages are reference counted, so I need to know when rx has finished with one. I don't think that the iovec mechanism will give me that ... [23:57:52] --- Rasmus Kaj has become available