[00:17:25] --- phalenor has left [00:27:56] --- phalenor has become available [01:23:55] --- Simon Wilkinson has become available [01:40:13] --- Russ has become available [01:44:42] --- Russ has left: Replaced by new connection [01:44:42] --- Russ has become available [02:15:50] --- Russ has left: Disconnected [03:59:10] --- Simon Wilkinson has left [04:48:13] --- Simon Wilkinson has become available [04:49:06] I suspect that the afsmonitor problem is due to a lack of prototype [05:41:23] --- jaltman has become available [05:58:57] --- meffie has become available [06:02:00] --- Simon Wilkinson has left [06:20:37] --- Simon Wilkinson has become available [06:35:35] --- Simon Wilkinson has left [07:08:34] --- deason has become available [07:28:46] --- jaltman has left: Disconnected [07:40:06] --- jaltman has become available [08:15:47] --- Kevin Sumner has left [08:47:21] --- matt has become available [08:55:49] --- jaltman has left: Disconnected [09:05:55] FreeBSD reclaim. The notion that we wouldn't call afs_FlushVCache in our vop_inactive (on the [09:06:21] reasoning that we should have done so in our vop_close or vop_inactive) I don't think holds up. [09:06:56] What the FreeBSD client port is doing is consistent with how the AFS CM has implemented the inactive vop for many forms of BSD, for long time. [09:07:57] Likewise those other vops. [09:08:12] (read vnops) [09:24:38] And, afs_FlushVS. I didn't track this when it went by some while ago. I'm confused--it seems that [09:28:22] DARWIN has the same use of afs_FlushVCache in its reclaim vop, and the BSD ports seem to be the only use in the source code of afs_FlushVS. [09:36:07] That just seems like a typographic error. [09:53:04] --- matt has left [10:03:20] silly question: what does the 'BP' branch prefix denote? [10:04:03] branch point [10:04:17] tho we can probably drop those in the git world [10:04:31] I don't grok that.. [10:04:40] which that [10:04:50] dropping or branch point? [10:04:55] or git world? [10:05:04] better yet, ask a question :) [10:05:55] is that 'BP' an artifact of gerrit, or how we have gerrit set up? [10:06:15] it has nothing whatsoever to do with gerrit. it's a relic of cvs [10:06:16] BP-foo is the CVS tag corresponding to the version from which foo was branched. [10:06:52] we probably don't need BP tags anymore and in fact the one i added should probably be removed. [10:07:20] It is, in fact, not a branch at all, and if it exists as one in git, that indicates an (unimportant) error in the conversion process [10:07:49] Oh, or that someone created a branch post-conversion when he should have created a tag, or done nothing. [10:08:50] BP-whatever was created with git tag, not git branch. the 1.6 branch is not named BP- whatever [10:13:40] In which case we go back to "it's not a branch at all" [10:25:15] --- rra has become available [10:25:53] Branch point tags are kind of pointless in Git, although I suppose it doesn't hurt anything. [10:26:10] Ah, I see that point was already made. :) [10:28:34] well, it can confuse git describe [10:39:43] --- jaltman has become available [11:28:12] --- matt has become available [12:05:00] There are some features of Gerrit 2.1.5 that we might want. http://gerrit.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.1.5.html [12:08:53] yeh. [12:18:47] which of those are things we care about? [12:37:43] inline commenting on commit messages would be nice... and not having "restore change" when you want it seems very very annoying [12:37:52] matt: (re reclaim) It is certainly the case that we need to do something more than vnode_destroy_vobject in vop_reclaim. FlushVCache is the existing function closest to my conception of what that "something more" should be, though it's not entirely clear to me (and I'm still rather new at this) that it is entirely the correct thing to do. I am probably going to just change FlushVS to FlushVCache and move on with my life for now. That said, I am curious why we don't free the vcache associated with the to-be-reclaimed vnode, instead putting it on a free list. (Which is really a free stack?) Granted, the comments around VOP_RECLAIM indicate that vnodes are contended, not memory, but they also indicate that the filesystem should be freeing its storage. Do we have a mechanism to limit how much memory is spent on vcaches other than malloc failing? [12:46:50] if you're just wondering "what's with this pool of vcaches that we keep around" in general... my impression from this the last time I looked at it in solaris is that we tend to not free vcaches, which is not what modern OSes expect us to do [12:46:55] but it's what's been around and it works [13:56:28] --- kaduk@mit.edu/barnowl has left [13:57:30] --- kaduk@mit.edu/barnowl has become available [14:06:50] --- jaltman has left: Replaced by new connection [14:06:51] --- jaltman has become available [14:24:28] --- jaltman has left: Disconnected [14:24:40] --- jaltman has become available [14:43:26] --- meffie has left [14:49:54] --- jaltman has left: Disconnected [15:23:55] --- jaltman has become available [16:07:55] --- deason has left [16:24:09] call for votes sent [16:28:56] huzzah [16:32:39] * rra ponders making jhutz thwap me by arguing that the voting should have been Condorcet. [16:33:26] * rra would have loved to be able to do some sort of preference ranking here. Oh well. [16:33:34] Probably more trouble than it's worth. [16:58:37] I fixed the FBSD vreclaim bug. [17:01:45] I sensed that I could. I'm sorry I didn't get to it earlier. [17:03:39] Thanks for getting to it at all. I've been kind of swamped with other stuff until just recently, so it hasn't been an issue for me, really. (Though it would be kind of sad if 1.6 was broken in this way.) [17:07:29] I'm going to bundle it with the change that reverts afs_FlushVS references for FBSD, OBSD, and NBSD, since even if something must be done differently there (I have no idea, beyond noticing DARWIN didn't follow), we can't just break the common case for these. I don't think that was intentional, but I guess I'll get comments if so. [17:08:27] Well, those calls were put in a long time ago -- are the people who did so even still around? [17:09:33] By "fix reclaim", do you mean that you tracked down where we lose track of 'opens'? [17:11:44] I didn't recall an afs_FlushVS. Before the disconnected change, we conditionally called afs_FlushVS only if AFS_DISCON_ENV. [17:12:00] Right, git doesn't know about a FlushVS, either. [17:12:03] Are you sure the afs_FlushVS is ancestral? [17:12:18] I don't think it ever was defined, only declared. [17:12:36] So, it's the opposite, and we should revert that away. It doesn't exist even on other ports. [17:12:55] Sure. [17:16:14] And no, I haven't sorted open completely, but I change osi_VM_FlushVCache to return EBUSY only if we have positive opens. I'm seeing the ability to traverse arbitrarily deep (and iteratively many times) with only 1562 vcaches. As it was, we were damaging the vm. I've clarified the comment at vgone(). Apparently, what I did there was safe, I am suspicious of the panic in vgonel(), but touch nuggies, I guess. [17:21:40] Yeah, opens was always -1 in close (?) or whatever for me, so I submitted gerrit/2321 . > damaging the vm Will this be clear when I look at the patch/commit message? [17:22:47] Will which be clear? [17:22:55] How we were damaging the vm [17:24:31] I am kind of hoping that the 'opens' leak is related to this behavior that I think is a bug where we leave a directory vnode Xlocked (e.g. when a user cd's into a directory). [17:26:55] Ok, well, 2321 sounds like it does the same thing. Why is this not committed? [17:29:10] The commit message, possibly, makes it sound, and the comment makes it sound, (and Derrick implied) as if the guard avc->opens > 0 is somehow wrong, but frankly, it's not. [17:29:43] I think Derrick wanted (him or me) to look harder for the 'opens' leak; I was assuming that it would get committed if we hadn't found the leak before the release was ready-ish. [17:30:19] I don't think that avc->opens is ever supposed to be negative -- it gets initialized to zero. [17:35:07] Well, I'll have a look at it. I can definitely produce the case without having a shell with wd in the path. [17:36:53] > /me would have loved to be able to do some sort of preference ranking > here. I thought about that, but the field is complex and probably controversial, and I didn't want to propose the vote-takers adopt any more complex a rule than we had to to solve the problem. [17:37:51] "the case" being the opens lossage? [17:38:46] A case where opens is, apparently, -1. [17:39:36] Okay. [17:40:19] Moreover, I have not produced deadlock traversing. I assume you have not? [17:41:19] I have not produced deadlock, no. Someone on a mailing list claimed that 'ls' would hang until some other operation finished -- I don't really remember the details offhand. Let me look. [17:43:03] http://markmail.org/message/bsszfkuoe2uddeda [17:43:45] (Fri, 23 Jul 2010 on freebsd-afs@freebsd.org) [17:45:53] If I break into ddb while no operations are happening in afs, but I have a shell in afs, there is a single locked vnode, corresponding to the directory I'm in. [17:54:45] Ok. I don't see the connection immediately, but I'm going to look further what happens after osi_TryEvictVCache. Because clearly opens was 0 there, or we wouldn't have called vgone() on it. [17:55:16] on AFSTOV(it) [18:31:31] --- rra has left: Disconnected [18:38:03] I begin to understand. We don't lose track of opens. [19:02:11] --- Jeffrey Altman has become available [19:14:50] --- jaltman has left: Replaced by new connection [19:14:51] --- jaltman has become available [19:16:22] --- Jeffrey Altman has left: Disconnected [19:16:35] --- Jeffrey Altman has become available [19:52:18] --- deason has become available [19:59:57] > Condorcet this is the reason / a reason I asked about how we change the process later; I didn't want to bother for bootstrapping [20:14:57] --- jaltman has left: Disconnected [20:19:07] --- jaltman has become available [20:29:36] Opens went negative by 1 because FBSD is calling VOP_CLOSE in vgonel(). In that case it's already asserted by us that opens == 0. I think I conclude that if, on entry to afs_vop_close, vp->iflag & VI_DOOMED, then assert(opens == 0), and return 0, not making a (superfluous) call to afs_close(). [20:29:50] That seems to be working nicely. [20:33:10] Sounds good to me -- Derrick and I had to track down a deadlock from that codepath; too bad we didn't connect the dots about the opens count. [20:36:52] Thanks for tracking that down. [20:38:32] That was something I hoped to get to a long time ago, it was good to look at it again. [20:41:04] My test box (a) panic'd due to an integer overflow bug in the timecounters, so I had to upgrade the OS, and (b) has been getting machine check errors, so I haven't gotten much useful done with it. [20:43:08] I used fbsd for byte-range lock testing and bugfixing, so I've had the opportunity. [20:43:30] Nifty. "Do they work, yet?" [20:43:48] Actually, pretty much, yes. I'm beating on async-issue parts. [20:44:18] Basic lock vops work on all bsds, solaris, linux, etc. [20:44:35] Awesome. [20:48:04] If I git push with 2 changes committed, will that turn into 2 changes for gerrit? [20:48:33] Yes. [20:49:26] (If the first one has already been pushed, the re-push shows up as a new patchset for that gerrit change. Which is sometimes annoying because I do not yet compulsively branch.) [20:51:58] Thanks, my git skills are narrow. [20:52:25] (or worse) [20:53:56] --- matt has left [20:55:18] In retrospect, it has been more helpful than I realized at the time, to have a SIPB office of git hackers to ask questions; I think I mostly understand what's going on, now, for my everyday use. [20:56:15] I guess it's a good thing most people don't know about that resource. [20:57:13] Well, it does have a rather high barrier to access, for most people. [20:58:24] Well, given that "most people" live in China, you're probably right. :-) [22:04:14] --- deason has left [22:19:40] --- jaltman has left: Disconnected [22:19:49] --- jaltman has become available [22:38:40] --- jaltman has left: Disconnected [22:38:48] --- jaltman has become available [23:01:17] --- haba has become available [23:08:51] --- Russ has become available