[00:47:49] --- lars.malinowsky has become available [01:46:34] --- Simon Wilkinson has become available [02:01:13] --- Simon Wilkinson has left [02:01:39] --- Simon Wilkinson has become available [02:02:10] Some of the 2.6.39 patches break on older Linuxes - don't know if that's a problem for Debian or not. [03:17:14] --- haba has become available [06:23:41] --- haba has left [06:37:03] --- Simon Wilkinson has left [06:44:46] --- reuteras has left [07:21:05] --- haba has become available [07:35:50] --- lars.malinowsky has left [07:52:59] --- deason has become available [08:38:17] --- haba has left [10:06:00] --- lars.malinowsky has become available [10:12:11] --- lars.malinowsky has left [13:39:32] --- rra has become available [13:39:50] Do you know how far back one has to go to get breakage? [14:33:20] --- mdionne has become available [14:34:42] f2e91cc3fe61956e7661eae9da82ddf746e63824 [14:35:19] oops, I meant to say that with the above commit you should be ok for all kernels [14:35:30] Oh, okay, cool. Thanks! [14:35:43] without it, i think 2.6.20+ is ok [14:36:30] Oh, okay, cool -- we should be good anyway, then. Nothing in Debian at this point is going to care about anything older than .32. [14:42:08] 2.6.39-rc1 is now out, so there's a good chance that will be all that's needed for 2.6.39 [14:42:29] cool [15:23:01] --- deason has left [16:01:41] --- Simon has become available [16:03:18] --- mdionne has left [16:07:57] --- mdionne has become available [16:13:14] --- Simon has left [17:24:55] Hmm, this time dd(1) hung, but the cachetruncatedaemon seems to be holding the glock ... [17:28:51] --- rra has left: Disconnected [17:38:34] Wait, WITNESS claims the glock is locked but afs_global_owner is NULL?! [18:04:08] --- jakllsch has become available [18:04:24] are vcaches ever unallocated? [18:04:52] "That depends" [18:05:08] But for your case, not really. [18:15:26] if i have a structure that needs to be in the beginning of the structure pointed to by v_data, where do i (un)initialize that? [18:16:04] it really belongs to the vnode [18:17:48] i'm sure i'll figure something out though :-) [18:32:28] Am I blind, or does just afs_WaitForCacheDrain being set not actually cause any dcaches or blocks thereof to be discarded? [20:17:30] --- jaltman/FrogsLeap has become available [20:28:34] --- mdionne has left [20:30:24] --- shadow@gmail.com has become available [20:33:33] cause: no. the periodic background daemon just does it, and wakes you if you're waiting [20:34:10] This being the CacheTruncateDaemon, or some other background daemon? [20:34:15] so the q would be what the background loop handler is doing [20:36:29] the cache truncate daemon [20:36:45] It's basically chilling. [20:37:00] is it [20:37:13] bothering to wake up and see if it needs to work? [20:37:25] sorry new to me client [20:38:02] this is why my question about msleep [20:38:36] I can probably offer a patch but not til [20:38:40] I am hone [20:39:01] ah. nice. it helpfully just sends when the line's too long [20:41:05] How thoughtful of it. [20:41:59] From piles of printfs, it takes the xdcache lock, takes the cachetoofull branch, goes through all 10 iterations of the for loop, releases the xdcache lock. cachetoofull and waitforcache drain are still set, and blocksdiscarded is zero. Then it does the 100ms free-up-the-glock sleep, calls freediscardeddcache, skips the stats block, and then goes back to the top of the while loop. [20:42:18] (I had to rate-limit the printfs so as to be able to even break to the debugger.) [20:44:48] I think it's past my scrollback, but I think it did actual things early on. [20:50:53] so all that's interesting are afs_GetDownD calls [21:01:19] --- shadow@gmail.com has left