[00:22:58] --- Russ has left: Disconnected [00:55:18] --- geekosaur has left [00:55:24] --- geekosaur has become available [01:33:50] --- shadow@gmail.com/owlD253A924 has left [02:03:41] --- geekosaur has left [02:03:41] --- geekosaur has become available [03:52:22] --- jaltman/FrogsLeap has left: Disconnected [06:01:58] --- meffie has become available [06:08:49] --- shadow@gmail.com/owl497D8295 has become available [06:56:34] --- kula has become available [07:24:48] --- deason has become available [08:23:28] --- jaltman/FrogsLeap has become available [09:42:49] --- rra has become available [10:49:28] --- deason has left [10:49:31] --- deason has become available [12:22:08] Where do the debian packages want the vice cache to live? [12:34:50] /var/cache/openafs [12:37:09] thanks [15:43:54] --- deason has left [15:53:15] --- deason has become available [15:54:20] --- jaltman/FrogsLeap has left: Disconnected [16:13:40] --- mdionne has become available [16:50:39] --- rra has left: Disconnected [17:09:10] --- Russ has become available [17:59:07] --- meffie has left [17:59:26] --- jaltman/FrogsLeap has become available [18:28:18] --- jaltman/FrogsLeap has left: Disconnected [18:33:27] --- jaltman/FrogsLeap has become available [19:07:53] --- mdionne has left [19:25:27] It looks like afs_vcount is supposed to count the number of vcaches *in use*, not the number which is allocated. So the setting of it to afs_maxvount in the initialization is not needed, but incrementing it when a vcache enters use is, which is not happening for FBSD. [19:27:13] Thus it would want to be incremented in afs_NewVCache_int, not afs_AllocVCache, according to my (overly-simple?) reasoning. [20:05:01] it's not just the number of vcaches in use; I asked that when adding the check in solaris to prevent you from umount'ing when vcaches are inuse... and as I recall I couldn't just use that number [20:14:52] er, vcount should be allocs, iirc and not in use [20:23:11] --- abo has left: Lost connection [20:23:11] --- mho has left: Lost connection [20:28:56] --- abo has become available [21:04:17] "Then why do I end up with -312666 of them after a buildworld?" [21:14:16] you might as well add the parts that are right [21:15:16] --- deason has left [21:20:31] --- jaltman/FrogsLeap has left: Disconnected [21:20:46] --- jaltman/FrogsLeap has become available [21:20:49] If my quick reading is correct, we do not deallocate vcache storage in flushvcache in either the afsd_dynamic_vcaches case or the static case. So the afs_vcount-- in it would be just wrong, provided that afs_vcount is supposed to count allocations not in-use. [21:22:03] --- jaltman/FrogsLeap has left: Disconnected [21:22:13] i'll go reread shortly. right now i am apparently swaptastic [21:22:21] Wheee. [21:22:45] I bet I don't actually want to go pull out the binders in the SIPB office. [21:22:58] binders? [21:23:37] We have a few binders of old documentation, which I want to say includes developer resources. [21:23:43] won't help [21:23:54] also, you can have digitals of most of it i bet [21:24:11] the arla ftp site has copies i gave them in like 1998 [21:24:24] Nifty. [21:24:39] not to mention they are still in my andrew cell space somewhere [21:25:53] like, probably /afs/andrew.cmu.edu/acs/asg/shadow/afs [21:32:08] --- jaltman/FrogsLeap has become available [22:25:54] if afs_vcount is supposed to count in-use, it already does. AllocVCache allocates it, and increments that. [22:46:10] --- Russ has left: Disconnected [22:49:58] ben, 3423 in gerrit [22:57:51] and 3424 are the changes for FBSD i detailed on zephyr. not yet tested.