[00:39:14] --- abo has become available [00:46:58] --- dev-zero@jabber.org has become available [01:42:07] --- Russ has left: Disconnected [03:08:13] --- haba has left [03:36:45] --- haba has become available [04:38:35] --- manfred furuholmen has become available [04:38:59] UV_PartitionInfo [04:39:20] replace by AFSVolPartitionInfo [04:39:21] ? [05:07:22] uh. no? [06:15:22] --- mmeffie has become available [06:46:46] --- deason has become available [07:20:27] --- matt has become available [07:48:17] --- reuteras has left [08:04:07] i have this error dyld: lazy symbol binding failed: Symbol not found: _UV_PartitionInfo [08:04:14] on perl library [08:05:02] what library? [08:05:13] yup. you need to update, UV_PartitionInfo64 is the current symbol [08:09:59] i try to change in the source .. [08:23:07] Segmentation fault :-< [08:23:45] did you fix things to use the right data or did you just change UV_PartitionInfo to UV_PartitionInfo64? [08:24:43] the fast ... just change [08:25:36] i hope was the same interface .. [08:25:55] i check the data now [08:31:10] it works [08:31:46] i figured. it's a simpel change [08:32:50] yes, very simple new interface and new structure . 4 lines [09:33:13] --- dev-zero@jabber.org has left [10:12:21] --- dev-zero@jabber.org has become available [10:14:30] --- Jeffrey Altman has become available [10:26:46] --- haba has left [10:47:42] --- dev-zero@jabber.org has left [10:50:23] --- manfred furuholmen has left [10:58:07] --- dev-zero@jabber.org has become available [11:07:22] --- dwbotsch has left [11:08:04] --- dwbotsch has become available [11:11:41] --- Rrrrred has left [11:27:00] --- Russ has become available [11:27:28] --- Russ has left: Disconnected [11:32:33] --- mmeffie has left [11:32:53] --- Russ has become available [11:51:48] --- deason has left: Lost connection [11:51:48] --- stevenjenkins has left: Lost connection [12:23:39] It's time to do regular patching of the system hosting git.openafs.org and gerrit.openafs.org, which will need a reboot. When's a good time? [12:58:20] --- summatusmentis has left: Lost connection [12:58:20] --- dwbotsch has left: Lost connection [12:58:20] --- kula has left: Lost connection [12:58:20] --- gendalia@gmail.com/owl613FDC66 has left: Lost connection [12:58:20] --- shadow@gmail.com/owl56156058 has left: Lost connection [13:56:49] --- haba has become available [14:05:02] --- stevenjenkins has become available [14:16:37] --- kula has become available [14:17:19] --- shadow@gmail.com/owlD22BA4DE has become available [14:17:56] --- deason has become available [14:18:05] --- Rrrrred has become available [14:18:20] --- summatusmentis has become available [14:18:30] --- manfred furuholmen has become available [14:21:06] --- dwbotsch has become available [14:21:09] --- gendalia@gmail.com/owl613FDC66 has become available [14:22:38] question: 'vos release' looks at the updateDate of rosites to determine when to dump from for the forwarding op; If the creationDate for an RO is newer than the updateDate, would it break anything to use that instead? [14:23:15] using the updateDate means we usually include a usually small but nonzero amount of unnecessary dump info [14:25:47] Yes, it would break releases. [14:27:04] The updateDate is the time of the last update before creation of the RO clone that is then dumped to create the copies on other servers. Those other copies may have creationDates that are newer, but that doesn't mean they contain changes to the original RW volume that are newer than the updateDate. [14:28:16] We sometimes include a small but nonzero amount of unnecessary dump info because there is a deliberate fudge factor to prevent fencepost errors. Changes made after the updateDate but before the creationDate of a clone are _not_ unnecessary. [14:29:29] --- manfred furuholmen has left [14:30:26] how would we get an ro vol with a creationDate after the last update? [14:34:49] Release: - Step 1: make an RO clone - Step 2: forward copies of the RO clone to other sites The updateDate freezes at the beginning of step 1. Any RO clones created on other sites in step 2 are created _after_ the updateDate stops moving. [14:44:01] Really, please don't break releases. Because if you do, someone will look at it, fail to notice some subtlely (which is easy, because there are lots of subtleties here, and we've spent hours in the past working through them), and commit it. And then three years from now we'll be tracking down a hard-to-identify volume corruption problem. [14:45:01] yes, that's why I was asking; and you're correct; sorry, it's annoying difficult for me to think about this correctly, apparently [14:46:43] I was annoyed by the vnodes included whose update was the one that made updateDate what it is; I thought that would always be unnecessary extra (unless it was going to be included anyway), but I guess that's unavoidable? unless the remote sites had the creationDate the same as the local clone [14:47:09] "annoyingly difficult", not "annoying difficult" [14:50:45] > it's annoying difficult for me to think about this correctly for anyone, really [14:52:09] hmm, isn't the creationDate of remote sites set by the forwarding dump, though? [14:53:14] (set to the same date as the clone'd RO, that is) [14:55:14] --- dev-zero@jabber.org has left [15:24:50] --- deason has left [15:34:05] --- deason has become available [15:50:40] --- matt has left [16:01:45] --- abo has left [16:02:31] --- abo has become available [16:47:06] --- kula has left [17:06:17] --- kula has become available [19:42:02] --- Jeffrey Altman has left: Replaced by new connection [21:05:30] --- Russ has left: Disconnected [21:21:24] --- Russ has become available [22:15:27] --- deason has left [22:18:00] --- reuteras has become available [22:43:32] --- dev-zero@jabber.org has become available [23:27:14] --- dwbotsch has left [23:27:27] --- dwbotsch has become available [23:55:11] --- Rrrrred has left