[00:39:35] --- dev-zero@jabber.org has become available [01:30:17] --- manfred furuholmen has left [01:44:46] --- manfred furuholmen has become available [01:57:16] --- manfred furuholmen has left [01:58:23] --- manfred furuholmen has become available [02:51:00] --- manfred furuholmen has left [02:52:05] --- manfred furuholmen has become available [03:16:57] --- Simon Wilkinson has left [03:16:58] --- Simon Wilkinson has become available [03:26:10] --- Simon Wilkinson has left [03:30:36] --- Simon Wilkinson has become available [03:40:57] --- SecureEndpoints has left: Replaced by new connection [03:43:50] --- tkeiser@sinenomine.net/owl has left [05:06:08] Looks like disconnected has a bug with truncating a file upwards in size ... [05:06:36] Don't do that :-) [05:12:52] --- tkeiser@sinenomine.net/owl has become available [05:25:13] fun [05:31:27] Yeh. The fsx suite that Jason pointed me at is giving ... interesting ... results. [05:47:02] isn't fsx in src/tests? [05:47:38] I don't know. I haven't delved deeply into src/tests. [05:48:30] But, it looks like the problem is that the normal code relies on the fileserver creating the chunks when extending files. Disconnected can't talk to the fileserver, and so you end up with a file with missing chunks. [05:48:54] src/tests/fsx.c i'd bet. [05:49:05] "yes" [05:49:25] yeah, that sounds plausible [05:51:01] The problem is that instead of just failing the write, the cache manager seems to manage to tie itself in knots. [05:55:01] fstrace? [05:55:09] istr issues with this once before. [05:55:21] the whole pos versus size thing, and a bug from haba [05:56:04] Yeh. Just about to go there. But I think the problem is in disconnected, rather than in the cache manager in general. We're being inconsistent about the sizes, I think. [05:59:33] But, it looks like 1.5.56 has broken disconnected in other ways, too. [06:00:05] testing on which platform? [06:00:26] Linux. Any attempt at a replay gets a UAEACCESS. [06:00:48] Hmmm. I wonder. [06:02:47] something wonky with afs_AccessOK? [06:02:58] PAGs [06:04:23] Turns out my session wasn't in a PAG, so when I did fs discon online as root, I had no tokens. Which == fail. [06:06:04] ah [06:07:57] And, unfortunately, not == "I'm sorry, you're being stupid. Please get a clue and try again", but "I'm going to drop all the pieces on the floor, and leave this directory in a state you can't recover from" [06:19:51] --- SecureEndpoints has become available [06:44:35] --- SecureEndpoints has left [06:52:10] --- dmontuori has become available [06:57:46] --- reuteras has left [07:41:30] hi all [07:42:43] hi [07:43:22] not sure if pepole have heard, GSoC 2009 is happening, and details will be announced at FOSDEM [07:43:43] just bringing it up, so we're prepared if we want to go that route again [07:43:53] Yup. jaltman posted about that. Now's the time to start thinking about what people could do, if we were to be accepted. [07:44:12] It's interesting that Google are having a presence at FOSDEM this year, too... [07:44:33] did I miss an email somewhere? don't remember seeing jaltman's post [07:45:01] not familiar w/ Google's OSS presence, normally. I had just assumed they were always there [07:45:23] Can't remember if it was here, or on IRC ... [07:45:47] oh, been vacationaing/travelling [07:45:58] s/vacationaing/vacationing/ [07:52:33] I don't recall seeing anything here. It was probably on IRC; for some reason the gsoc people were all hanging out there, where they didn't get to interact with the rest of us. [07:53:06] we didn't have jabber when we applied for gsoc [07:53:40] and we like IRC better (we being I) :-P [07:54:08] About the only thing I prefer IRC to is poking my eyes out with sharp sticks. And that's a close run thing. [07:54:54] I can't make that comparison, Simon; I try to avoid doing either. [07:55:07] :) [07:55:56] i hate irc [07:56:11] owl has made it tolerable [07:56:23] meh, it's really the only MUC option I have any experience with [07:56:36] You mean, aside from this [07:56:58] yes, but even jabber I'm relatively new to [07:57:47] I still say moving to jabber was the wrong answer; we should have just set up a zephyr realm and given everyone accounts [07:58:14] zephyr still doesn't work behind nat [07:58:25] i still think zephyr >> jabber except that [07:58:26] And K5 Zephyr isn't exactly widespread. [07:58:47] Or wasn't, when we were talking about ways of communicating better. [07:58:50] That's OK; I was thinking we'd give them a place to ssh to. :-) [07:59:40] Of course, you wouldn't be able to run just anything there. Only a screen running barnowl. [08:00:00] (hm, that would require barnowl to have a restricted mode) [08:21:48] wrt GSOC, is there going to be a discussion some time? [08:24:54] I think at the moment the focus is on thinking about ideas we could have as projects, and people who could possibly mentor them. I'd strongly advise prospective mentors to consider the time that's required. I reckoned I probably spent 10 or so hours a week mentoring last summer - and I think being prepared to make that kind of time commitment is pretty crucial to getting a successful outcome. [08:31:11] as a student last summer, having a mentor easily accessible, and always available (replying to email in a timely fashion, etc.) was crucial [08:34:54] --- Moose has become available [08:38:08] today on "weird questions i've never thought of before:" [08:38:29] is there any known problem with setting a pts groupquota to, like, 50? [08:41:45] i can't think of any, and i'm pretty sure i've seen system groups iwth huge quotas [08:41:51] but i've never really thought it through [08:45:44] sxw - yes, having a GSOCer or summer intern is time consuming. [08:48:04] you're just not drugging them enough [08:51:37] I tend to try to hire somewhat intense and hyper interns; the passive ones just don't work well w/my style. [09:07:05] --- dev-zero@jabber.org has left [09:13:31] moose: remind me never to work for you [09:24:48] Most of my ex student slaves loved working for me [09:29:58] I dn't know, maybe depending on the kind of drugs it could be fun >_> [09:32:49] zomg someone is creating groups with -owner groupid, and groupid's group quota ran out [09:32:57] now he's trying to insist that it's because HIS quota ran out... [09:33:25] wait... hrm. it might be [09:33:29] this is... WRONG [09:36:03] Grrr. The Linux implementation of CTruncate only shrinks files. But gleefully returns success if you ask it to extend one. [09:48:04] --- dev-zero@jabber.org has become available [09:53:34] --- Simon Wilkinson has left [09:54:11] --- Russ has become available [10:01:16] > is there going to be a discussion some time? [10:01:18] namely? [10:01:44] we only suggest projects. students can propose whatever they like. it's hard to know who the right mentors are until we know what the proposals are [10:02:32] should people use the Twiki to suggest projects? [10:02:53] e.g., so that people can see what's already been suggested, get ideas, etc. [10:03:08] would probably be easiest, at least at this stage? [10:03:21] sure, that's fine. encouraging discussion of those here, irc or on the list is also good, but it's not something we need to pick a time for or all be around, rather than, say, an ongoing discussion [10:03:33] granted [10:03:35] --- Simon Wilkinson has become available [10:32:25] --- manfred furuholmen has left [10:38:17] No, it's right. Group quota is about how many groups you can create, not how many you can own [10:38:52] that's bogus [10:39:17] There's no reason for a *user* to get points knocked off for creating a subgroup of another group [10:39:27] No, it's not. The idea is to keep people from exhausting the available space by creating lots of gratuitous groups. That wouldn't work if you could create lots of gratuitous groups and then give them away. [10:40:21] again, it's bogus. *I* shoudl be limited to 20 groups, as a user. Group Foo, probably being used by an org who needs a pile of subgroups, should have it's own quota, which is used for making said subgropus [10:40:55] So that I can steal your group quota by giving away groups to you? [10:41:09] When *I* make a subgroup of the main group, with -owner, then -owner should have it's quota taken aawy [10:41:17] dude, were you around for cat:has_a_nice_ass ? [10:41:34] So I can take away your group quota by making groups owned by you? [10:41:45] no, because i'm not a group [10:41:48] i'm a me [10:42:23] Well, leaving aside for the moment the fact that groups don't have group quota... so I can take away your group's quota by making groups owned by it? [10:42:36] only if you're in the gropu! [10:42:41] that's the point of having system groups! [10:43:16] hahaha anyone can give away a group to any owner [10:43:34] Can you give away a system gropu? [10:43:47] What's a "system group" ? [10:44:23] oh gods, whatever they're called this week. i used to call them "supergroups" (which is what pierette & david & ted called them, Way Back) until that got taken over by group-within-groups [10:44:28] groups with + ids [10:44:43] A PTS entry with a positive ID is called a "user" [10:45:11] you're being a dick intentionally again, aren't you [10:45:18] postman, for example, is a user [10:45:51] those supergroups were never documented as called that [10:46:02] --- dmontuori has left [10:46:04] No. The rules for users are different from those for groups. [10:46:09] --- dmontuori has become available [10:46:11] yes, a role account is not a supergroup [10:46:12] actually i meant a userid with a - id [10:46:13] so there [10:46:20] ok [10:46:25] a userid that has userids within [10:46:42] Users, for example, are not owned, so no one can give them away. They also don't count against anyone's group quota. The do have their own group quota, which is used for groups they create. [10:49:00] Oh, a group with no : in its name? Yes, you can give those away. The only things different about those from regular groups are - only sysadmins can create them - since they have no prefix, their name doesn't change when they change owners. You can give one away, if you own it. [10:49:50] --- dmontuori has left [10:50:02] --- dmontuori has become available [11:02:57] --- dwbotsch has left [11:03:34] --- Rrrrred has become available [11:06:32] even still. - ids should have a working quota from which -id:subgroup is removed [11:13:20] vos getvnode -- ick. vos getfid would be better, I think [11:15:54] vos gettea/vos getcoffee [11:16:05] new palm device being announced! [11:16:27] vos createnewvoscommand [11:17:19] as long as it's self-recompiling [11:18:00] vos ouroboros [11:19:17] dammit i've wanted vos getcoffee for YEARS [11:19:37] vos gettea would be more useful. [11:19:47] feh [11:19:51] too british :-P [11:20:05] Or vos please-fix-the-annoying-bugs-in-this-code [11:20:29] vos stop-firing-the-moose :-P [11:20:57] You just need to wait until mooses are out of season again. [11:21:11] i live in the snowbelt now, that's about never [11:21:39] --- dmontuori has left [11:21:45] --- dmontuori has become available [11:22:08] that's "stop firing on mosses" [11:22:10] mooses [11:23:07] Yes, I suppose 'stop firing mooses', probably involves the outlawing of catapults, cannons and the like. [11:26:49] ban the trebuchet! [11:35:22] --- Moose has left [11:36:26] Well, I've now fixed extension so it works whilst disconnected, but it looks like mmap() is broken. Ho hum. [11:37:26] --- Moose has become available [11:41:04] We seem to have some bugs even whilst connected though - fsx reports truncation problems (fsx truncates the file to 0x3a5c, AFS returns a file that is 0x4000 in size). This is with the latest 1.5.x [11:54:28] It looks like it's racing with pdflush ... here's an extract from fstrace. [11:55:02] time 220.144480, pid 2563: Setattr vp 0xcfb8c780 mask 0x2068 newlen (0x0, 0x491) oldlen (0x0 , 0x3494e) time 220.144486, pid 2563: TruncAll vp 0xcfb8c780 old len (0x0, 0x3494e) new len (0x0, 0x491) time 220.144772, pid 2563: RXAFS_StoreStatus vp 0xcfb8c780 len (0x0, 0x491) time 220.154927, pid 182: Iupdatepage ip 0xcfb8c780 pp 0xc1100a00 count 0x2 code 99999 time 220.154931, pid 182: Write vp 0xcfb8c780 off (0x0, 0x0) resid (0x0, 0x1000) file length (0x0, 0x491) time 220.188238, pid 2563: Analyze RPC op 5 conn 0xcef47620 code 0x0 user 0x41664f74 time 220.188243, pid 2563: Getattr vp 0xcfb8c780 len (0x0, 0x491) time 220.188300, pid 182: /home/sxw/openafs/src/libafs/MODLOAD-2.6.27.9-73.fc9.i686-SP/afs_vnop_write.c line 701: m.Length was (0x0, 0x491), now (0x0, 0x1000) [11:55:12] pid 2563 is fsx, pid 182 is pdflush. [11:56:47] unfortunate. i bet the fix i just did for that wasn't sufficient [12:03:58] So recently as to not be in the tree yet, or something older? [12:04:25] it was fixed in 1.4.8 [12:04:31] (for 1.4.8 that is) [12:04:56] Ah, so it should be in the tip of 1.5.x, then. [12:06:01] yes [12:22:10] Should we not be holding a lock when we call truncate_inode_pages() ? [12:25:04] i thought we did, but if it's just xvcache that;s not likely enough [12:27:56] I think, from reading around that we should hold the inode mutex. I need to check current kernel headers, though. [12:28:01] s/headers/source/ [12:39:54] > ids should have a working quota from which -id:subgroup is removed So, we're back to, I should be able to create a group owned by you and thereby steal your quota [12:47:11] ya know, that's the same bullshit as "pts chown is a security risk" [12:47:50] You cannot create a group owned by me and steal my quota, you shoudl have the groupquota assigned to the owner. PERIOD. [12:50:54] If the groupquota comes from the owner, you have three problems: 1) By creating groups owned by you, I cause _you_ not to be able to create groups. 2) Groups can be owned by groups, which don't have quota -or- I can get infinite quota by creating groups 3) You end up with a limit on the number of groups someone can own, rather than on the number that can be created, which fails to serve the intended purpose of group quotas, that being to prevent a malicious user from easily exhausting the group ID namespace. [12:52:42] Given the current quota model, pts chown is a security problem only for people who have the expectation that there are group names (other than prefixless groups) which are only available to certain people. [12:54:17] Hrm, which actually gives me a neat solution to an access control problem I've been pondering. If, instead of granting special powers to members of sys:proj.foo, I grant them to members of something like sys_proj.foo, then there will not be a hole that allows a user to give themselves admin powers for a project whose group does not yet exist. [12:55:20] Thank you, moose. Even though I expect we will continue to disagree on whether group quotas and ownership should have BSD or SysV semantics, this conversation has been very useful, at least for me. [13:03:23] Nope, it's not a lack of i_mutex - that's held by the VFS layer before we get called. [13:15:30] --- manfred furuholmen has become available [13:29:25] --- dmontuori has left [13:29:42] --- dmontuori has become available [14:57:12] --- manfred furuholmen has left [15:14:39] --- dmontuori has left [15:14:55] --- summatusmentis has left [15:16:10] --- Moose has left [15:20:04] --- edgester has become available [15:20:16] edgester: Thanks for that bug report. [15:20:39] Simon Wilkinson: You're welcome. I hope it was helpful and complete [15:21:04] Indeed it was. I've found (and fixed) the bug for disconnected that you found, but fsx is turning up some other interesting issues. [15:21:20] excellent! [15:21:25] There's a race condition between writing and truncation in the connected cache manager, which is ... interesting. [15:21:41] in connected mode? [15:21:48] Yes [15:21:57] hmmm [15:22:20] Have you tried fsx in connected mode? [15:22:29] is it between writing, or between writeback? [15:22:35] and truncation [15:22:55] It's between pdflush calling write_end, and truncation. [15:23:12] yes, I ran it in connected mode. It skipped some passes, but I didn't investigate. Things seemed ok. [15:24:02] I'm wondering if its to do with when we update i_size, in relation to when we truncate the files on disk. [15:26:13] Actually, that's a lie. Latest test that's just completed died in a race between writepage and truncate. After 86,000 operations ... [15:26:33] mmmm racy [15:27:34] I did wonder if it was because we weren't using the i_size_read and i_size_write macros to update i_size. [15:28:10] (writepage is called without i_mutex locked, and i_size_read provides a race-proof mechanism of reading the size). But it isn't that ... [15:30:57] Actually.... How's this for a theory... [15:32:08] We truncate the segments pretty early on in afs_setattr. After that, we release locks in order to allow a number of RX calls to occur. We don't update the Linux inode structure until afs_setattr() returns, so the kernel thinks the inode size is much larger for quite a considerable period of time. [15:33:12] actually, that's a pretty good theory [15:34:01] Right. I'll try patching that and see what happens. [15:47:16] --- SecureEndpoints has become available [15:48:15] I need to try to compile fsx on windows and see what bugs show up in windows [15:49:31] I found lots of tools that the ntfs-3g team uses to test their code. I plan to try those out. Better to not reinvent the wheel... [15:55:29] Indeed. [15:55:54] --- matt has become available [16:26:01] edgester: Does fsx ever actually terminate? [16:41:14] Well, after half a million operations, I'm tempted to say that that's that bug fixed ... [17:05:42] Simon Wilkinson: w/disconnected, yes. w/connected. I killed it after a few minutes. [17:05:54] Simon Wilkinson: w/disconnected, it died. [18:15:52] --- summatusmentis has become available [18:58:47] --- edgester has left [19:03:55] --- dev-zero@jabber.org has left [19:24:33] --- matt has left [19:54:23] --- dev-zero@jabber.org has become available [22:09:16] --- stevenjenkins has left [22:11:01] --- stevenjenkins has become available [22:21:20] --- dev-zero@jabber.org has left [22:21:27] --- Russ has left: Disconnected [23:04:28] --- reuteras has become available [23:10:50] --- dev-zero@jabber.org has become available [23:43:32] --- manfred furuholmen has become available