[00:05:31] --- Russ has left: Disconnected [01:55:00] --- cclausen has left [02:11:57] --- geoffreyerffoeg@gmail.com/owlE4C5279C has left [02:19:29] --- dwbotsch has left [02:20:18] --- dwbotsch has become available [02:23:27] --- RedBear has left [02:37:09] Yeh, cvsps does have branching issues. Essentially, if you make branch, and then the next commit isn't onto the newly cut branch, the branchpoint will be put in the wrong place. [04:00:26] --- dev-zero@jabber.org has become available [04:00:32] --- dev-zero@jabber.org has left: offline [04:34:15] --- shadow@gmail.com/owl52607589 has left [04:50:26] --- kula has become available [05:27:27] --- Jeffrey Altman has left: Replaced by new connection [05:41:04] --- shadow@gmail.com/owl72BABB76 has become available [06:34:57] We've also got some great points in the tree where the revision that's in a tag isn't in the same branch as the rest of the code. Those are really fun. [06:40:11] the revision that... what? [06:40:34] Take a look at src/vol/clone.c in openafs-devel-1_5_20 [06:41:03] The tagged revision is 1.25, which is actually on the HEAD, not on the openafs-devel-1_5_x branch. [06:45:11] i wonder what happened there [06:45:36] I wonder if the tag was done from a working directory that had one file cvs updated from HEAD in it. [06:45:52] i assume so [06:45:59] presumably i did it. [06:46:16] It's actually harmless, because the file on HEAD and the revision in the branch that should be in that tag match. [06:47:01] yes. tho fixing the vault file seems trivial [06:47:23] But please don't :) Not till I've got a copy for the migration. [06:48:31] Actually, if you fix the vault, then the contents of that release tarball, and the contents of the repository will differ, because the bogus revision will be in the $Revision$ string in that file, in the tarball. [06:49:15] ah true [06:49:29] i'm not touching it anyway; i meant if you wanted to fix it [06:49:39] Please don't edit the vault files. Hasn't this experience taught you that that sort of thing is a Bad Idea? [06:49:58] I've just got an ever growing list of exceptions ... [06:52:20] what experience would have taught him that editing vault files was a bad idea? [07:00:01] --- cclausen has become available [07:22:39] --- Jeffrey Altman has become available [07:23:33] --- matt has become available [09:52:37] --- Russ has become available [10:27:45] --- dev-zero@jabber.org has become available [10:27:51] --- dev-zero@jabber.org has left: offline [13:09:14] --- cclausen has left [13:22:22] the current state of 1_5_x is...new vols at least don't require salvage? [13:22:28] sorry dafs [13:22:38] dafs: no clue [13:22:42] non dafs, no [13:24:37] The bugs in RT would seem to suggest none of the DAFS bugs have yet been resolved. [13:26:19] hm. [13:26:42] I believe you should see fixes to some shortly. e.g., the 'new dafs vols dont require salvage' [13:27:00] and some of the signal handling [13:27:34] it would be helpful to get some feedback wrt which are viewed as show-stoppers for 1.6. [13:30:15] "if you want dafs to ship, it would be nice if it worked as well as non-dafs"? [13:31:44] right. that's a reasonable approach. [13:32:04] however, some of those 'bugs' are 'fileserver scalability', which apply to both dafs and non-dafs. [13:32:17] true [13:34:02] I think the big show stopper for 1.6 is testing. Experience strongly suggests that there is ~no-one running 1.5 on their servers. [13:37:48] i've wanted to run 1.5 here, but never get the time/resources to do so, alas. which is sad, some of dafs stuff could be very useful to us. [13:38:36] yeah, I talked to someone today who is getting ready to run 1.4.10 + DAFS instead of 1.5. [13:38:47] "someone" [13:38:53] * stevenjenkins nods. [13:39:33] I asked 'why not 1.5 instead?' and the answer was 'it's a good idea, but it doesn't fit our timeframe'. [13:40:04] ie, he felt 1.5 was too untested and would rather use 1.4.10 + DAFS instead. argh. [13:42:22] how well tested is the -noresolve option to vos commands? [13:42:43] Works whenever I've tried it. [13:42:47] Are you seeing problems? [13:42:50] tested well enogh that we know it doesn't resolve? [13:42:52] vos exa root.cell -noresolve [13:43:03] root.cell 536870912 RW 173 K On-line debug1.endpoint.com /vicepa [13:43:13] what's in /etc/hosts? [13:43:29] not debug1.. [13:43:44] 'fileserver scalability': which bugs are this? [13:44:05] one sec ,matt, while I pull up the list [13:45:26] 124488 [13:45:31] 124489 [13:46:34] actually, it looks like there may be fixes for a few of the others: 124484, 124490, maybe 124483; 124482, 124492 and 124486 [13:47:10] it's hard to do that mapping in my head, though, and I know I've confirmed some 'fixed, but not upstream'. [13:47:33] 124488: salvage performance [13:47:35] tkeiser has been swamped lately, so I don't know the latest. [13:48:16] 124489: volattach performance (dafs) [13:48:54] one of those two, I don't recall which, *is* actually worse for DAFS than for non-DAFS. [13:48:59] 124484: salvsync (dafs) [13:49:03] (erg) [13:49:47] tom and I have been discussing some improvements for quite a while now, but I don't know the status (I haven't touched DAFS except for getting those tickets into OpenAFS since December or so). [13:50:01] I take that back: I wrote some tests a month or two ago. [13:50:03] 124490: correctness in volops (dafs only? all the internal tkt names are) [13:51:16] 124483: correctness in volops (dafs only? all the internal tkt names are) [13:52:36] 124482: sometimes report pre-attached vols as online (dafs) [13:53:10] 124492: new vols needs salvaged (dafs) [13:53:34] 124486: dafs fileserver hangs on shutdown (dafs) [13:54:22] so steven, the improvements you're referring to are in fssync and salvager areas? [13:55:33] one sec - otp [13:59:51] ok. anyway, for that last 6, it would certainly be good to get the fixes upstream, esp 124492 [14:00:04] and 124486 [14:02:26] yeah, I know 124492 is on its way upstream. [14:02:34] excellent [14:02:52] as is 124486 [14:02:56] woot [14:03:53] by the way steven, how are you fixed for fileserver scalability -tests-? [14:04:25] well, there's this guy I know who runs a large site... [14:05:19] and I have a pretty decent virtual environment for testing, but that's not about scalability. [14:05:35] oh. well, perhaps that approach would work. I have this patch where you can create a lot of threads and cache a lot of fds. [15:13:24] --- cclausen has become available [16:40:04] --- matt has left [16:52:17] --- tkeiser@sinenomine.net/owl has become available [17:55:38] --- Russ has left: Disconnected [18:12:26] --- Russ has become available [19:52:03] --- Jeffrey Altman has left [20:23:12] --- Jeffrey Altman has become available [20:24:06] --- Jeffrey Altman has left [21:23:41] --- Jeffrey Altman has become available