[00:24:40] --- dev-zero@jabber.org has become available [00:24:47] --- dev-zero@jabber.org has left: offline [01:06:51] --- sxw has become available [01:15:12] --- sxw has left [01:18:00] --- sxw has become available [01:28:28] --- sxw has left [02:01:01] --- Russ has left: Disconnected [02:19:15] --- dev-zero@jabber.org has become available [02:19:20] --- dev-zero@jabber.org has left: offline [02:24:37] --- sxw has become available [03:17:26] --- sxw has left [03:36:02] --- sxw has become available [03:54:30] --- mmeffie has become available [04:12:41] --- sxw has left [05:26:37] --- SecureEndpoints has left: Replaced by new connection [05:36:26] --- sxw has become available [05:40:28] --- SecureEndpoints has become available [06:19:33] --- sxw has left [06:19:34] --- sxw has become available [06:48:28] --- sxw has left [06:55:33] --- sxw has become available [07:04:57] http://docs.openafs.org/ is slowly being populated. top level index and unix quick start guide are present. need to figure out how to generate version number on the fly using xsl [07:42:20] User Guide generated [07:47:18] 'fs mariner' is hidden because it's a historical alias, not really meaningful to anyone who doesn't already know about it. 'fs monitor' is hidden because it's useless unless you have the tool it talks to, which AFAIK we don't ship. [07:55:11] what is the tool it talks to? [07:55:59] venusmon Really, you should stop worrying about this. It doesn't do what you think it does. It has nothing to do with statistics of any kind. [07:56:41] (it's hidden for a reason) [07:57:08] I'm fine w/that -- the only reason I'm fiddling w/it is that it's listed as one of the commands that needs documentation. [07:59:25] That's debatable. If you're of the school that everything should be documented, then it needs documentation. But it does not need to be unhidden. [08:04:52] I suspect the list of required man pages was a list that was generated of every command (hidden or not) that was listed in a command line tool for which there were no man pages. [08:05:46] commands that were maintained in openafs tools to support infrastructure we do not support do not necessarily in my opinion need to be documented by us. [08:20:01] Admin Guide is now generated [08:20:56] ah, right, i forgot venusmon. probably /afs/andrew.cmu.edu/usr/shadow/venusmon.c [08:21:24] QuickStart and User Guide for Windows do not exist at present. Everything I can generate is now present. [08:21:35] Going to look at the version number issues [08:44:18] --- sxw has left [09:04:19] --- dev-zero@jabber.org has become available [09:06:04] --- sxw has become available [09:08:14] --- dev-zero@jabber.org has left: offline [09:37:04] So what changed in the fileserver between 1.4.8 and 1.4.10 ? [09:46:43] AdminGuide and UserGuide regenerated with automated indexes. Windows HTMLHelp versions are now also available. [09:49:55] As for the file server, the viced deltas are STABLE14-viced-threadnum-return-cast-20090323 STABLE14-viced-type-fixups-20090323 STABLE14-cbd-new-magic-version-with-fixed-time-size-and-dump-switch-20090319 STABLE14-viced-improve-host-hashing-20090315 STABLE14-viced-copyonwrite-optimization-20090315 STABLE14-undo-viced-copyonwrite-optimization-20090315 STABLE14-dumpcallbackstate-64bit-timet-safe-20090310 STABLE14-rename-residency-from-mrafs-to-osd-20090119 STABLE14-viced-callback-20090110 STABLE14-audit-consolidate-open-20081217 [09:52:07] and the vol deltas are: STABLE14-vos-reveal-hidden-cmds-20090427 STABLE14-volid-cast-unsigned-int32-20090323 STABLE14-vos-increment-offline-count-20090218 STABLE14-vclosevnodefiles-ihandle-leak-20090216 STABLE14-vol-fsync-20090128 STABLE14-vol-dump-incr-largefile-support-20081222 STABLE14-audit-consolidate-open-20081217 [09:52:17] There's also a few global config changes. [09:54:50] --- sxw has left [09:54:59] and in case the issue is Solaris specific STABLE14-solaris-largepartition-interface-20081222 [09:58:14] IH_OPEN. Now that sounds familiar [10:00:37] See STABLE14-vclosevnodefiles-ihandle-leak-20090216 and ticket 124359 [10:26:47] --- Simon Wilkinson has become available [10:30:13] that was my guess [10:31:51] Anyone for 1.4.11 ? :) [10:32:11] sounds like Hartmut has a fix. [10:32:38] Is STABLE14-vclosevnodefiles-ihandle-leak-20090216 not the fix? [10:32:44] I'm not sure that the above delta is wrong though. [10:33:02] No, ignore me. My dates are well off. [10:33:07] that delta is in 1.4.10 [10:33:22] Yeh 2009-04-02 got read as 20090204 [10:33:49] I'll go back to sleep now ... [10:34:00] :) [10:34:32] you can review the admin and user guides at docs.openafs.org to put yourself to sleep [10:35:19] Nah, I've got LDAP schema to write which will acheive that. If I start reading docs, I'll start writing patches, and that doesn't end well. [10:39:09] i guess when meredith starts processing mail i'll see the thread you have [10:39:27] i was already looking at the 1.4.8->1.4.10 diff for this very thing [10:44:14] https://lists.openafs.org/pipermail/openafs-info/2009-May/031381.html [10:45:43] that's not really a fix. the inode shouldn't be missing [10:46:07] oh, the handle in the vnode. lemme read [10:48:05] i was leery of this whole background sync thing all along. i should have been leerier. [10:52:05] Is the background sync thing, the less-fsyncs patch? [10:59:56] yes [11:01:58] I think it introduced a race [11:04:57] --- tkeiser@sinenomine.net/owl has become available [11:19:00] --- Russ has become available [11:29:09] The "Workshops" link on the openafs.org homepage leads to a page with no mention of the 2009 workshop ... [11:34:23] http://grand.central.org/workshop appears to suck, yes [11:35:22] interestingly it's not obviously served from afs. hm. [11:35:35] Can someone make it suck less, or can we just change the "Workshops" link in the sidebar to go to workshop.openafs.org [11:36:06] well, i'm sure someone can. i'm trying to determine if i am someone [11:36:17] ... which is both more recent, and not a hideous FRAME abuser [11:38:49] i have no idea if someone is me. if grep tells me someone is me, i will fix it. i repointed the navbar link. it's publishing now [11:40:03] Cool. Thanks. [11:46:15] > interestingly it's not obviously served from afs. No, it's not. It's part of the GCO home page, and comes from htdocs-gco [12:16:42] --- kula has left [12:18:59] --- kula has become available [12:45:37] > returning EIO might be smarter, yes [12:45:50] would also require major code restructuring [12:46:50] Yeh. I took a look at that. There's no much opportunity for the users of CFileOpen to register disgust. [12:47:08] yup [13:20:54] it occurs to me, if the client ever gets ENOENT in answer to something which a cached directory claims should exist, we should probably flush [14:00:32] That would seem reasonable. Flush, or just clear CStatd? [14:01:01] just clearing CStatd is probably sufficient [14:01:23] If you're disconnected, then it might not be. But that's something I'm nervous about anyway ... [14:01:39] s/you're/you have been/ [14:01:40] if i'm disconnected, i can't solve the problem [14:01:44] oh [14:02:39] Basically, disconnected changes cache data without touching the version number. Providing everything syncs right, then all of the changed files get put back to the servers, and their version numbers updated. But if something goes wrong ... [14:03:23] right [14:03:32] we discussed fake version numbers, right? [14:04:17] We didn't. We need to be careful, because we need the valid DVs for collision detection. [14:05:19] i know we discussed *something* in this space [14:05:33] Fake FIDs? [14:05:43] maybe [14:05:58] fake cells, at least, sounds familiar [14:06:45] Originally, the code didn't tidy up after itself at all. What we're shipping does try to makes sure that nothing that's been written whilst disconnected can slip out into the connected world (by clearing Statd everywhere, and by flushing anything that didn't sucessfully replay) [14:07:49] So, I think we're good, baring any unfortunate omissions. But, it is one case where just clearing CStatd when we get ENOENT wouldn't suffice. I don't think it's a good enough reason, on its own, to do anything more heavy handed, though. [14:08:55] it's good enough reason to think more about the problem [14:09:36] I did wonder a while back whether there was any mileage in chunk hashes. But that was for a different problem. [14:10:12] ideally you'd want the fileserver to be able to answer whether a given chunk of data had a certain hash, or rather, what it was [14:10:38] and i proposed adding an RPC for that at some point for easing backups thru the filesystem users or something of that ilk [14:11:25] Yeh. That's roughly what I was thinking. So you can easily verify the integrity of your whole cache, even when your version numbers have gone a bit screwy. But this is pretty edge case, though. [15:35:29] --- cclausen has become available [15:56:11] --- matt has become available [16:41:32] --- matt has left [17:36:33] --- edgester has become available [18:55:48] --- tkeiser@sinenomine.net/owl has left [19:04:39] *woosh* And the first edition of the newsletter is away [19:05:33] --- edgester has left [19:40:33] --- mmeffie has left [19:49:37] --- SecureEndpoints has left: Disconnected [20:12:13] --- SecureEndpoints has become available [20:36:06] --- matt has become available [20:59:46] --- dlc has become available [21:41:50] --- matt has left [22:46:02] --- Russ has left: Disconnected [23:05:48] --- reuteras has become available