[01:10:09] --- Russ has left: Disconnected [01:12:51] --- haba has become available [03:12:03] --- steven.jenkins has left [03:14:26] --- steven.jenkins has become available [04:39:07] --- Simon Wilkinson has become available [05:40:35] --- Simon Wilkinson has left [05:46:20] --- haba has left [05:54:06] --- Simon Wilkinson has become available [05:54:53] --- Simon Wilkinson has left [05:55:01] --- Simon Wilkinson has become available [05:55:14] --- Simon Wilkinson has left [05:56:02] --- Simon Wilkinson has become available [06:39:41] do we have an ETA on 1.6 stable? (or, better yet, did I miss the announcement) [06:40:40] no [06:41:02] any general idea? [06:41:20] at the euroAFS conference we were presented with the fact that 1.5.77 is 30% slower than 1.4.12 [06:42:03] rx, cm, fs, all of the above, or 'unknown'? [06:42:45] we have discovered issues with Rx performance which is where all of the recent commits to Rx are coming from. However, it is unclear if there are performance regressions at other layers [06:43:02] ok. thank you. [06:44:18] do we have more information on the regression somewhere? e.g., test suite for replication & analysis purposes [06:46:13] or if having that would be of help, I'd be glad to talk with whomever and get that assembled so that it would be easier for the community to see that 'ok, the changes have addressed that' [06:46:41] the test suite used by the HEPIX storage working group is not public. However, you should be able to replicate the results by using a single client machine with multiple processes (no tokens) reading large files continously from a variety of volumes on the same server. compare 1.4.12.1 performance to 1.5.77 [06:47:07] The rx issues can be replicated using src/test/rxperf.c [06:51:20] ok, thank you. [07:02:51] --- Simon Wilkinson has left [07:06:57] --- deason has become available [07:43:13] --- mho has become available [10:30:54] --- rra has become available [12:07:29] --- ezyang@mit.edu/barnowl has left [12:10:08] --- andersk has left [12:35:09] --- andersk has become available [12:35:20] --- ezyang@mit.edu/barnowl has become available [13:06:33] --- Simon Wilkinson has become available [13:06:50] Does anyone have any objections if I take gerrit down for a quick upgrade? [13:08:18] I think we've reached consensus that if the outage is expected to be 5 or 10 minutes, just do it. [13:26:01] Just done it :) [13:41:32] --- shadow@gmail.com/owl7980BB5C has become available [13:43:05] --- jaltman has left: Disconnected [14:18:58] gerrit's using http:// urls for the "cherry-pick" et al options... not that it really matters much, but isn't the git:// protocol a bit less overhead? I thought that's what they used to be [14:19:20] I think you can now configure it yourself. [14:22:01] I'm not seeing it, but that wouldn't be the first thing I've just been blind to [14:22:17] You can select between Anonymous HTTP, HTTP and SSH. [14:22:38] I don't know if git:// should be there too, or not. Maybe I need to tweak a configuration setting in the new version. [14:23:55] oh it's on the thing where I get the url, I was looking in preferences for some reason [14:24:40] maybe it was always http://, I thought I remembered otherwise, but now that I actually look at the interface I'm not sure [14:24:49] by default, that is [14:28:10] Hmmm. I wonder if I've broken gerrit emails. [14:50:12] rra: > It continues to be the belief of many people inside Debian that Nexenta is illegal does the stuff in that email mean specifically for nexenta, or would the same probably go for also illumos, that theoretical gnu/kopensolaris project, etc ? [14:50:54] (that's re: openafs-info traffic, for the confused) [14:53:07] As I understand it, the Nexenta issue is that they link GPL'd code with CCDL code (such as Sun's libc) and then distribute the result. [14:57:46] Yeah, what Simon said. [14:58:17] They're claiming they can use the system library exception, but since they're distributing both the binaries and the libraries, it's the opinion of a lot of people in Debian that they obviously cannot use that exception. [14:58:54] As long as the userspace doesn't involve CDDL libraries, they're probably fine. Kernel to userspace is a pretty clear license firewall. [15:00:34] yeah, I just found the debian-legal thread: http://lists.debian.org/debian-legal/2010/09/msg00001.html [15:01:53] I can't see how Nexenta is a solution to any of the Oracle problems, though. If they're only getting a source drop every 24 months (if that) for the kernel, they're either going to have to invest a large amount of their own resources into kernel development, or they're going to bitrot spectacularly. [15:02:52] Nexenta has felt like a solution in search of a problem for a while to me. To the extent that the goal is to get interesting Solaris features out into the free software world, well, I'd rather run FreeBSD with ZFS, honestly. The rest of Solaris I think is more of a drawback than a feature. But I know some people disagree with me. [15:03:11] Zones I guess is the other major thing that people like. [15:03:17] dtrace [15:03:28] Point. But doesn't BSD have that too? Mac OS X does. [15:03:38] and zfs on freebsd I thought was not as stable; not that I would know [15:03:42] The service management stuff is at this point inferior to either upstart or systemd. [15:04:18] I was about to say smf, too, but the last time I used it was before upstart was feasible for me [15:04:48] dtrace: yeah, well, I personally don't have bsd or os x systems :) [15:05:15] there's a linux dtrace-like thing, too, but from what I saw it was quite lacking in features [15:05:44] dtrace requires serious intrusive kernel modifications. It's a big committment. [15:05:58] and wasn't there that company porting zfs to linux, just avoiding gpl-only symbols? [15:06:09] Man, good luck with that. [15:06:16] I suppose we manage. :) [15:06:25] I know ZFS under FUSE is working on Linux, but eh. [15:06:47] we'll have someone else to complain about gpl-only symbols alongside us :) [15:07:01] There are three ZFS ports. [15:07:10] There's a FUSE one, which works entirely in userspace. [15:07:21] > If they're only getting a source drop every 24 months or illumos [15:07:33] LLNL have done a kernel port of the ZFS block device, because they want to use that with Lustre. [15:07:55] And there's an Indian company that have produced the ZFS posix layer, and release that. [15:07:57] But even with the code drop thing, I wonder how long it will be before that code drop starts looking like what Apple did with Darwin, where you get less and less of the total source base until it's not really that horribly useful. [15:08:34] depends on what you need it for; having darwin code is really useful for trying to figure out what some kernel interfaces actually do, and stuff like that [15:08:39] --- ksumner has left [15:08:40] http://zfs-fuse.net/ http://zfsonlinux.org/ http://zfs.kqinfotech.com/ [15:09:02] --- ksumner has become available [15:09:09] Also, more generally, code drops are kind of useless even if they continue. If no external work is ever incorporated and there's no feedback mechanism, and you have to rebase everything with each code drop for arbitrary development that was never publicly discussed, about the only good code drops are is what you mention -- an adjunct to kernel API documentation. [15:09:18] They're kind of useless for actually maintaining an OS. [15:09:27] Of course, the real issue with ZFS isn't the code at all, it's the spectre of NetApp's patent portfolio. [15:10:16] Oracle is historically been very hostile to free software, and that doesn't seem likely to change from where I sit. [15:16:28] --- jaltman has become available [15:20:37] Yes. Moving towards code drops is a sure fire way of killing any external involvement. It's not really open source at all at that point. [15:20:48] Nexenta is actively developing ZFS which at this point means forking. Being able to migrate a pool from Solaris 11 to Nexenta and back is likely to fail. [15:21:10] There was minimal external involvement. Really minimal [15:24:47] > It's not really open source at all at that point. emacs worked that way for a long time, I thought [15:25:13] to some extent it can be argued that nginx works like that; I wouldn't say it's impossible [15:25:48] yeah, which is when XEmacs split off. Since Emacs started using a real open source development model, it took off again, and XEmacs is mostly dying. [15:25:51] Similar thing happened with GCC. [15:26:00] http://www.nexenta.com/corp/blog/2010/09/28/apac-netapp-and-oracle-and-openstorage/ [15:26:36] I still can't figure out what role Milkowski has in this [15:52:02] --- deason has left [16:07:39] > zfs on freebsd I thought was not as stable I am given to understand that this is no longer the case; stability has been improved quite a bit recently. [16:26:50] --- Simon Wilkinson has left [16:41:26] --- shadow@gmail.com/owl7980BB5C has left [16:47:48] --- shadow@gmail.com/owl238F635B has become available [17:02:31] --- jaltman has left: Disconnected [17:09:51] --- jaltman has become available [18:29:26] --- rra has left: Disconnected [18:32:44] I have a sha1 of a commit, but no local repository. What's the fastest way to pull up that commit in a browser? [18:45:58] --- deason has become available [18:46:39] http://git.openafs.org/?p=openafs.git;a=commit;h= [18:47:53] Ah, thanks. [18:50:29] --- Russ has become available [18:59:32] did you get the sha1 from gdb perchance? [18:59:57] I did in fact :) (I almost added "I bet Derrick even knows which sha1 it is") [19:00:18] c39aee89c0649561041e7d955dd3db40629f2570 [19:00:47] Ayup. [19:01:45] i replied to jessica the first time i saw a complaint of the problem but had no data until now [19:03:27] I guess I should have saved the cmdebug output I got a couple weeks ago, then :-/ [19:03:33] probably [19:31:49] --- Russ has left: Replaced by new connection [19:31:49] --- Russ has become available [21:41:47] --- deason has left [22:18:00] --- ezyang@mit.edu/barnowl has left [22:26:23] --- ezyang@mit.edu/barnowl has become available [22:30:08] Hm, linerva had another event. /afs/athena.mit.edu/user/k/a/kaduk/Public/linerva-cmdebug-2010-10-01 [22:32:12] But cmdebug doesn't output until recovery, it seems. [23:05:03] if linerva is seeing the same issue that DESY is seeing, that behavior is expected