[00:12:20] Yes, but for speed, you are much better pulling from git://git.openafs.org, rather than ssh://gerrit.openafs.org [00:12:28] (it's also nicer to the server) [00:21:41] --- haba has left [00:38:31] In Git ≥ 1.6.4, you can git config remote.origin.url git://git.openafs.org/openafs.git git config remote.origin.pushurl gerrit.openafs.org:/openafs.git [00:39:39] --- reuteras has left [00:40:17] --- reuteras has become available [00:49:58] --- dev-zero@jabber.org has become available [01:35:48] --- Simon Wilkinson has left [01:37:07] --- kaj has become available [01:39:49] --- haba has become available [01:58:58] --- kaj has left [02:08:56] --- kaj has become available [02:29:04] --- kaj has left [02:45:58] --- Jeffrey Altman has left: Replaced by new connection [02:45:59] --- Jeffrey Altman has become available [02:58:20] --- Simon Wilkinson has become available [03:33:52] --- kaj has become available [03:39:56] --- kaj has left [03:43:57] --- cudave has left: Disconnected [03:49:28] --- kaj has become available [04:04:12] --- cudave has become available [04:12:48] --- kula has become available [04:33:11] --- Simon Wilkinson has left [04:33:11] --- Simon Wilkinson has become available [07:15:02] --- deason has become available [07:20:31] --- meffie has become available [07:20:36] wrt speed, that's not what I've seen.... pulling from gerrit is about 3 or 4 seconds faster for me when there's nothing to fetch [07:23:14] The thing is, when you pull direct from gerrit, you're using the gerrit applet to talk to you. And the sshd in that applet is known to not scale well. [07:24:22] ... that's why we've been moving to all of the pull URLs being git://git.openafs.org/ [07:25:37] --- Simon Wilkinson has left [07:30:41] --- summatusmentis has left [07:35:17] hmm, and github appears to be faster than both; is that pushed to with each commit or master/1_4_x cherry pick? [07:36:08] and.... 503 errors again. i hope you guys get this [07:36:09] --- kula has left [07:36:18] ok, trying again. [07:36:31] every gerrit commit should go to git.openafs.org and to github at the same time [07:40:22] stuff that gets picked on the min branches, right? not every individual gerrit submission [07:40:26] --- summatusmentis has become available [07:40:31] main branches (or whatever) [07:40:44] at the moment we only have gerrit things to master or 1.4, so... [07:41:10] when we start doing other stuff the config may need to be revised [07:49:21] --- kula has become available [07:52:23] --- Simon Wilkinson has become available [07:53:28] deason: github gets everything on a branch. But not tags [07:53:45] Sorry, mistyped. It gets branches, tags, but not changes. [08:10:01] Simon: so, when I s/bzero/memset/, I then want to git commit --amend before pushing to gerrit? Or is it smart enough to do the right thing for a simpler workflow? [08:10:10] changes and deltas are what makes our git instance slow. Every time you sync, it checks all 2000 or so entries in refs/changes, and all 10,000 or so entries in refs/deltas [08:10:20] kaduk: Do you have changeIds enabled? [08:11:44] Yes [08:11:55] Okay. So you need to git commit --amend [08:12:14] (with suitable git add, or git commit --amend -a, to make it include the thing you've just changed) [08:12:21] Okay. Out of curiousity, what would I need to do if I didn't have changeIDs enabled? [08:13:43] You'd need to do the next bit differently. [08:13:44] --- abo has become available [08:13:54] With changeIds, just git push to refs/for/master [08:14:11] It is a handy feature to have, it seems. [08:14:20] Without changeIds, git push refs/changes/ [08:14:22] without them you need to push to refs/changes/1234 etc [08:14:51] which, as you can imagine, results in several pushes to the wrong change... [08:15:01] Indeed. [08:17:12] --- reuteras has left [08:17:35] The big advantage of changeIds comes when you're pushing a rebased stack of changes. [08:17:57] or, you can push one at a time. good luck. [08:18:11] Without them, you have to individually target each SHA1 at a gerrit change number. [08:18:59] You end up with things that look like git push ssh://gerrit.openafs.org/openafs deadbeef:refs/changes/1 abcdef:refs/changes/2 000000:refs/changes/3 and so on. [08:19:09] And you need to get each of those right or changes get dropped. [08:19:14] changeIds rock in comparison. [08:24:11] Oh, and gerrit should now also catch the favourite trick of doing git commit --amend without adding anything to the index. [08:29:53] --- Simon Wilkinson has left [08:36:09] --- haba has left [09:12:50] ok, *fyre around? [09:13:52] --- Simon Wilkinson has become available [09:16:13] and now gerrit seems to not be letting me push to it. [09:19:06] --- kaj has left [09:19:28] What error are you getting? [09:23:34] it just times out [09:23:43] Hmmm. [09:24:12] seems to be timing out again [09:24:15] I wonder if we've hit the mina sshd deadlock (which is the other reason not to pull from it) [09:24:56] My network here seems to be breaking, sadly. [09:24:57] wait. [09:25:12] ok, uh, it's working. i bet the nat router here sucked [09:25:39] Looks like there might be a routing loop at stanford, too. [09:25:54] i dunno. [09:26:01] that push worked, and the web site never didn't work [09:26:19] shrug. look at 1561, stab your eye, and go enjo your evening [09:26:26] I will if I can. [09:26:39] (Look at 1561, that is) [09:28:15] Looks good, I think. [09:28:31] We need to think about dropboxes more before 1.4.13... [09:29:33] it's specialer on macos. anyway. go enjoy [09:30:44] going. But before that. [09:31:09] ? [09:31:12] Shawn has just released gerrit 2.1.2. I want to deploy this sooner rather than later, because it has lots of new exciting bits in it. I will probably do so this weekend [09:31:31] > We need to think about dropboxes more before 1.4.13... why? [09:31:43] i dunno if jeff is ready for 1.5.73. aside from conflicting there maybe, i don't care. 1.4.12 is done [09:31:58] jhutz: because right now we leak information [09:32:01] Because we backed out a security fix that we really should take because it broke them in 1.4.12 [09:32:20] I'd like to get a fixed version of that fix into 1.4.x sooner rather than later. [09:32:34] client or server? [09:32:40] client [09:32:49] info from the cache is leaked to callers not so entitled [09:33:12] Oh, I see. We can't win. But yeah. [09:33:47] having a better understanding of the issues would be nice [09:34:37] it really should be fixed, it's security and not a feature. but we failed to come up with a fix that worked for 1.4.12 [09:35:15] --- abo has left [09:35:31] I think I know what the fix should look like - basically we need an additional flag that we can pass in that says "I'm testing for dropbox rights" [09:35:44] But I need to think some more about it before putting pen to paper. [09:35:48] Anyway, for now, GONE. [09:35:50] yup [09:35:53] --- abo has become available [09:36:05] --- Simon Wilkinson has left [09:39:21] was the problem with the now-reverted dropbox fix that we were preventing people from stat()ing files they dropped, or did the additional perm check just completely break something else? [09:39:45] well, anyway, *fyre your dropbox issue is fixed. i will upload a fixed leopard build later. snowleopard build is there in about 30 seconds, and my lunch is going to be going in me. [09:40:26] well, among other things it tickled a macos bug [09:40:51] apparently leaking stat info makes coreservicesd not explode :\ [10:32:22] --- shadow@gmail.com/owl5BDB22A1 has left [10:50:12] --- Russ has become available [10:58:08] --- kaj has become available [10:58:47] --- haba has become available [11:03:00] --- abo has left [11:03:00] --- kaj has left [11:03:26] --- haba has left: Lost connection [11:04:10] --- kaj has become available [11:04:11] --- abo has become available [11:04:44] --- haba has become available [11:05:01] --- abo has left [11:05:01] --- kaj has left [11:05:59] --- abo has become available [11:06:07] --- kaj has become available [11:10:02] --- abo has left [11:10:02] --- kaj has left [11:11:09] --- kaj has become available [11:11:11] --- abo has become available [11:15:01] --- abo has left [11:15:01] --- kaj has left [11:15:09] --- haba has left: Lost connection [11:15:30] I'm not ready for 1.5.73. I need to finish up the krb5_get_error_message changes and I'm still trying to reproduce the Access Denied error on Win7 that has been reported on IRC in recent weeks. [11:15:39] I should be ready by this weekend [11:16:12] --- kaj has become available [11:16:57] --- abo has become available [11:17:27] --- haba has become available [11:20:02] --- abo has left [11:20:02] --- kaj has left [11:20:41] --- kaj has become available [11:20:49] --- abo has become available [11:25:02] --- abo has left [11:25:02] --- kaj has left [11:25:12] --- shadow@gmail.com/owl1EC0AB93 has become available [11:25:13] --- haba has left: Lost connection [11:26:06] --- haba has become available [11:26:39] --- haba has left [11:26:52] --- abo has become available [11:30:01] --- abo has left [11:31:17] --- abo has become available [11:35:02] --- abo has left [11:35:40] --- dev-zero@jabber.org has left [11:35:51] --- dev-zero@jabber.org has become available [11:36:36] --- abo has become available [11:39:25] --- kaj has become available [11:40:01] --- abo has left [11:40:02] --- kaj has left [11:40:41] --- kaj has become available [11:41:01] --- abo has become available [11:45:02] --- abo has left [11:45:02] --- kaj has left [11:46:01] --- abo has become available [11:46:08] --- kaj has become available [11:48:11] --- meffie has left [11:50:02] --- abo has left [11:50:02] --- kaj has left [11:51:04] --- abo has become available [11:51:12] --- kaj has become available [11:55:02] --- abo has left [11:55:02] --- kaj has left [11:56:13] --- kaj has become available [11:56:50] --- abo has become available [12:00:01] --- abo has left [12:00:01] --- kaj has left [12:01:10] --- kaj has become available [12:01:18] --- abo has become available [12:02:40] --- dev-zero@jabber.org has left [12:05:02] --- abo has left [12:05:02] --- kaj has left [12:05:41] --- kaj has become available [12:05:52] --- abo has become available [12:10:02] --- abo has left [12:10:02] --- kaj has left [12:11:02] --- abo has become available [12:11:12] --- kaj has become available [12:15:01] --- abo has left [12:15:02] --- kaj has left [12:15:52] --- abo has become available [12:16:08] --- kaj has become available [12:20:02] --- abo has left [12:20:02] --- kaj has left [12:21:47] --- kaj has become available [12:21:55] --- abo has become available [12:25:02] --- abo has left [12:25:02] --- kaj has left [12:26:04] --- abo has become available [12:26:17] --- kaj has become available [12:30:02] --- abo has left [12:30:02] --- kaj has left [12:31:13] --- kaj has become available [12:31:17] --- abo has become available [12:35:01] --- abo has left [12:35:01] --- kaj has left [12:36:11] --- kaj has become available [12:36:29] --- abo has become available [12:40:02] --- abo has left [12:40:02] --- kaj has left [12:41:13] --- kaj has become available [12:42:49] --- abo has become available [12:45:01] --- abo has left [12:45:02] --- kaj has left [12:46:15] --- kaj has become available [12:46:29] --- abo has become available [12:50:02] --- abo has left [12:50:02] --- kaj has left [12:51:11] --- kaj has become available [12:51:24] --- abo has become available [12:55:02] --- abo has left [12:55:02] --- kaj has left [12:57:13] --- kaj has become available [12:57:25] --- abo has become available [13:00:02] --- abo has left [13:00:02] --- kaj has left [13:01:18] --- kaj has become available [13:01:47] --- abo has become available [13:04:18] --- abo has left [13:04:18] --- kaj has left [13:05:53] --- abo has become available [13:06:30] --- kaj has become available [13:18:36] So, a couple days ago I was playing around with my freebsd client (with questionable event locking); I could mount /afs and use system:anyuser operations. I could get tokens, and run a privileged bos command. However, I could not use my tokens for fs or vos commands, nor for actual file operations. Furthermore, if I remember correctly, somewhere in the process of such a failed file operation, my tokens disappeared. Any thoughts on what might be at fault? [13:21:48] do you get any messages from the kernel? [13:22:21] --- haba has become available [13:22:59] --- Simon Wilkinson has become available [13:23:26] I don't remember seeing anything -- I was working at the console since I was expecting it to panic eventually. [13:23:48] but it would sound like the kernel is giving userspace progs the correct tokens, but when it tries to directly communicate with fileservers it doesn't use them correctly [13:23:52] --- Kevin Sumner has left [13:23:57] Not entirely. [13:24:01] vos is userspace too. [13:24:12] you might have lost tokens in an fs op [13:24:14] Being able to do bos, but not vos, suggests that there's a problem with ubik. [13:24:33] But yeh, only fs operations will cause the kernel to dispose of tokens. [13:25:03] Well, I am less certain about the vos commands; I don't actually remember what I was doing. [13:25:46] So, the simplest thing to check is that osi_Time is working correctly, [13:26:02] (if that's bad, then your tokens will disappear pretty much as soon as you try to use them) [13:26:25] Beyond that, take a look at the packet trace - are you getting rx aborts with rxkad error numbers? [13:26:47] (fstrace will also tell you that, and in newer versions, we do tell you why we're throwing tokens away in dmesg) [13:28:00] > packet trace As in rxdebug or as in tcpdump? [13:28:24] well, when *fyre reappears, have a dmg which should handle dropboxes for you. same place as before [13:28:34] rxdebug doesn't trace packets, so... [13:32:21] tcpdump [13:32:21] --- dwbotsch has left [13:35:33] --- dwbotsch has become available [14:01:35] --- dev-zero@jabber.org has become available [14:08:15] --- dev-zero@jabber.org has left [14:08:25] --- dev-zero@jabber.org has become available [14:34:41] Does anyone know where the statement "the maximum number of objects in an AFS directory is usually between 16,000 and 25,000" in the documentation originated from. [14:35:16] --- steven.jenkins has left [14:35:45] not a clue. ams usually topped out at 31707. [14:35:51] By my sums, these numbers seem a little low - 16,000 objects implies that every object has a 4 slot name (80-112 characters) which seems unlikely. 25,000 implies 3 slot names (48-80 characters). I haven't done any metrics on typical file lengths. [14:35:56] ams? [14:36:22] andrew mail system. "we have this hammer, ..." [14:36:46] Ah. Okay. [14:37:03] Did it use names longer than 16 characters, perchance? [14:37:28] --- steven.jenkins has become available [14:37:28] --- steven.jenkins has left [14:37:33] +4v6D6Xa00UfA016FM0 [14:38:37] i have no idea why i still have that message. it's from 2001. somewhere there's a tool to decode the filename. [14:38:49] --- abo has left [14:38:53] Yeh, and it's just long enough to put it in 2 slots. [14:39:04] --- abo has become available [14:39:21] I wonder if they realised they could get twice as many files if only they'd cut a few characters. [14:39:49] they *should* have. i doubt they did [14:40:38] From our local experience, the complaints we're getting about maxing out directories hit at around the 30,000 - 40,000 object point. [14:40:50] Do you think I should patch the docs? [14:40:56] probably [14:41:20] I'll knock something together. [14:42:58] Hmm. That text is from Jason, in efba39ea. I wonder where he got those numbers from. [14:43:45] Ah, from jaltman : http://www.openafs.org/pipermail/openafs-info/2008-January/028412.html [14:44:28] I guess the average filename might be longer on Windows... [14:47:18] --- haba has left [14:47:54] those numbers came from work with Pictage [14:48:23] Do they have seriously long filenames? [14:48:59] there are similar limits with some scientific projects that encode meta data in the file names [14:50:26] --- haba has become available [14:50:27] The problem is that this is so dependent on your use case. But I'm not convinced that a directory with all filenames longer than 80 characters is normal use. [14:51:04] --- abo has left [14:51:20] --- abo has become available [14:52:07] the average length of file names auto generated by microsoft word in one of my personal directories is well over 80 [14:52:27] I suspect that's true of Windows, I doubt that's true of Unix. [14:53:16] it is highly dependent on the use case. I wouldn't throw those numbers in the docs without clarification of the use case that generates them [14:53:32] They are in the docs, sadly. [14:53:48] that can be fixed [14:55:28] I wonder what would be better. We already explain the maths behind the calcuation. [14:57:52] I forgot the other aspect of the problem. MacOS X double files [14:59:10] Maybe something like: "In real world use, users who make heavy use of long file names may see a maximum number of objects as low as 16,000." [14:59:11] I think that we need to describe some specific use cases. [14:59:44] users of applications that make heavy use of .... [15:00:10] Okay. [15:00:19] MacOS X double files will reduce by 50% the number of visible files that can be created in the directory [15:00:27] I guess that number could actually be 8,000 on Mac OSX if you're storing metadata. [15:02:09] Of course, if you're really pathalogical, the complete upper limit on Mac is 3600 files per directory. [15:05:35] > users of applications that make heavy use of .... It's not Word that forces you to use document names like "Letter to some client rescheduling work so I can see my mother on her birthday" [15:06:55] But, in other situations, it might be the application. We have a corpus analysis package here that forces the use of 160 or so character filenames, and won't allow sub directories. [15:19:26] --- deason has left [15:51:28] --- phalenor has left [16:01:29] --- phalenor has become available [16:59:30] --- Russ has left: Disconnected [17:02:28] --- deason has become available [17:22:25] --- Russ has become available [18:21:46] (starking to this morning) I didn't realize that commits pushed to gerrit also go to openafs.git. [18:22:24] gerrit.openafs.org is git.openafs.org [18:22:31] so, sorta [19:55:39] will try the dropbox dmg tomorrow, if I remember [20:00:55] ok [20:21:47] in fact, let me set myself a reminder [20:23:17] Hm. I'm still a bit confused as to how to go from a changeID to a diff on my local machine. [20:24:36] why do you need to do that? [20:25:07] Because I don't want to start X and look at the web interface when I know that I am going to panic my machine. [20:25:41] Admittedly, that may not actually be what I *need*, but ... [20:26:08] none of which answers my question [20:26:11] (My immediate goal is to test your patch in 1554) [20:26:38] you need to git pull refs/changes/54/1554/5, i guess [20:27:12] I, uh, don't think I actually want to pull it. I can just show it, I hope? [20:29:13] so git fetch it. [20:37:11] hysteresis$ git fetch refs/changes/54/1554/5 fatal: 'refs/changes/54/1554/5' does not appear to be a git repository (same error if I take out the '54/') [20:41:36] sure. i was telling you what to fetch, not where to fetch it from. i assume it's git fetch git://.... refs/changes/54/1554/5 [20:42:03] i guess git://gerrit.openafs.org:29418/openafs refs/changes/54/1554/5 [20:42:19] Ah. [20:42:21] or perhaps without the :29418 [20:42:53] Oer perhaps gerrit refs/... since I have gerrit as a remote. [20:43:28] however you wanna do it [20:43:30] --- Born Fool has become available [20:45:57] --- abo has left [20:46:37] --- abo has become available [21:29:37] --- Born Fool has left [21:35:47] --- Born Fool has become available [21:35:51] --- Born Fool has left [21:36:40] Okay, I'm looking at a tcpdump of while I was trying to create a file with my tokens (which I retain after the failure, now). I see: rx abort fs reply create-file error #4973388 (32) after the rx call to create the file, and nothing else from rx. [21:57:19] --- dev-zero@jabber.org has left [22:03:22] --- reuteras has become available [22:31:08] --- dev-zero@jabber.org has become available [22:32:18] --- deason has left [22:37:21] --- dev-zero@jabber.org has left [22:38:43] --- dev-zero@jabber.org has become available [22:54:54] --- shadow@gmail.com/owl1EC0AB93 has left [22:54:56] --- kula has left [23:49:11] --- Simon Wilkinson has left [23:58:28] --- Russ has left: Disconnected