[00:16:23] --- lars.malinowsky has left [01:07:46] --- lars.malinowsky has become available [03:00:13] --- Simon Wilkinson has left [03:13:46] --- phalenor has left [03:13:52] --- phalenor has become available [05:04:24] --- meffie has become available [05:55:33] --- deason/gmail has become available [07:18:00] --- lars.malinowsky has left [07:18:12] --- lars.malinowsky has become available [08:02:01] --- lars.malinowsky has left [08:05:55] > Is there consensus that reporting each volume as a separate device > would be a good thing, if we have the capability to do so? insofar as the platform can handle it; would fbsd have any problems as you get into thousands, tends of thousands, etc mounts? [08:16:23] > would fbsd have any problems as you get into thousands, tends of thousands, etc mounts? this has been the question which precluded us from doing it elsewhere [08:24:51] if you can integrate with the automounter or something it seems like it may be okay; I know I've seen systems with at least hundreds of automounted nfs shares [08:33:02] the real issue is if the data is traversed as a linked list anywhere, on a multiuser system like the mit scripts machines it's going to scale like ass. [08:34:02] i looked at this for the macos finder problem and came to some conclusion as to why it wouldn't work there. i wish i knew where my notes were. or maybe i am grepping my zlog for the wrong thing [09:15:37] --- lars.malinowsky has become available [09:31:42] --- rra has become available [11:27:57] --- jaltman/FrogsLeap has left: Disconnected [11:31:12] --- jaltman/FrogsLeap has become available [12:02:05] --- Jeffrey Altman has become available [12:03:27] --- jaltman/FrogsLeap has left: Replaced by new connection [12:03:27] --- Jeffrey Altman has left [12:03:28] --- jaltman/FrogsLeap has become available [12:26:09] > would fbsd have any problems as you get into thousands ... mounts? Well, this came up in a thread on freebsd-fs about possibly going to a 64-bit dev_t. (There were three people talking about openafs before I even saw the thread (!)) The proposal there is to not have each volume be a separate mount, but to change the st_dev which is presented, so that userland utilities would know that they are crossing a mount point. A similar approach is used for NFSv4 mounts, which can cross server mountpoints. Provided there is some scheme for ensuring global (per-client) dev_t uniqueness, it should be reasonable, if I am understanding things correctly. [12:28:55] deason: re 4885, ?> is .ALLSRC, at least according to my make.1 (http://www.freebsd.org/cgi/man.cgi?query=make§ion=1) hmm, there's a display bug for me so that both ? and > show up as _ ... should poke someone about that. I ran a test change in 4881 to see if it would work everywhere, but I should have mentioned that change in the commit message as well. Sorry. [12:39:35] I don't know if it "officially" exists outside of bsd; although it appears to work in gnu make and aix make, I can't find it in their documentation anywhere [12:40:04] as you've seen it does't work on irix; it also doesn't work on solaris and I'd guess it won't on hp-ux either [12:40:18] Quite plausible. [12:41:00] I don't think you'll find anything that works reasonably on all platforms; I think we tried to find something when talking about AFS_CCRULE, but we couldn't so we just list the sources in the command to execute [12:41:27] That is my suspicion. [12:42:02] Which kind of feels like a step backwards, coming from the BSD infrastructure where I just say SRCS= foo.c bar.c baz.c vnode_if.h and tell it to go, and the right thing happens. But oh well. [12:44:07] if the worst thing you have to do is list the sources twice, you are in much better shape than most of the openafs build system [12:44:25] :) [12:45:22] and well yeah, it's going to be more annoying than something that only needs to work on bsd [12:58:55] Workshop materials? Anyone? :) [12:59:07] Getting pressure to do my write-up for our department. [12:59:23] Saw nothing to the workshop-attendees list yet. [12:59:42] "the workshop was neat" doesn't qualify? [12:59:49] Unfortunately, no [13:31:40] we will not be publishing a workshop attendees list this year [13:31:58] we are having trouble with the videos and webex [13:32:09] wasn't wanting an attendees list :) [13:32:11] posting slides: I haven't had any time [13:33:42] solving the MS11-043 problem and getting a release out that contains a fix is a bit higher priority for me [13:33:57] where would they be hosted? could someone else get the files from you, and do it? [13:34:35] you don't have bits and I can't give them to you [13:34:53] ok, just a thought [13:37:25] if it's the grand.central.org cell, i can give you bits easily enough but i have no way that i know to make you an account [13:37:35] Dropbox -> Share -> workshop-attendees-2011@secure-endpoints.com [13:37:38] but okay, whatever [13:38:07] um no [13:38:55] --- Russ has become available [13:39:03] yeah, see, won't dropbox. could put it in random afs space more easily. don't want to do the work twice. [13:41:04] Okay, well, at least I raised the issue, which is all I can do. Getting those materials for review, aside from my write-up to our department, is a big deal for me. So I've said it. I understand that the Windows issue/release takes priority, when delegation is not possible apparently. [13:48:54] (fwiw, slides for the talk i gave are at /afs/sinenomine.net/user/mmeffie/public/talks) [13:49:41] everyone was supposed to be able to download the shared materials from the webex training center and continue to login to it for 48 hours after the training to review things. things didn't work out as planned so there wasn't someone in place to collect everything and organize it. if there workshop had been done in person, the slides would have been presented from their final resting spot off the workshop website. not so much this year. [13:54:30] --- jaltman/FrogsLeap has left: Disconnected [13:54:37] --- jaltman/FrogsLeap has become available [13:59:39] > if the data is traversed as a linked list anywhere there's a linked list of mounts, but doesn't need to be one of dev_t's, I think. [14:07:09] --- pod has left [14:10:20] a dev_t is... what, 64 bits? [14:10:39] are you going to just assign a prefix to be only used by afs? [14:12:50] we should have talked with rick macklem about it in ottawa. [14:16:56] it just doesn't seem to really solve the problem thoroughly... you can get by if you assume volume ids are always 32 bits and you never talk to more than N cells, but there's a limit there [14:17:22] dev_t is only 32 bits at present. [14:17:29] --- shadow@gmail.com/barnowlA109197F has left: Lost connection [14:17:52] that seems even harder, then; how do you stuff a volume id in there? :) [14:18:29] There was some talk of exporting a dev_t auto-assigner from devfs for general use, which would presumably give unique values. It's not yet clear to me whether we need to ensure that the volume<-->dev_t mapping need be fixed for the entire lifespan of the client. [14:19:25] ah, okay [14:19:55] Which, kind of annoying, but we still have the VID in the vcache entry. [14:21:33] --- shadow@gmail.com/barnowlA109197F has become available [14:38:04] --- meffie has left [14:38:04] --- jblaine has left [14:42:01] --- jblaine has become available [14:43:17] --- meffie has become available [15:06:12] --- jaltman/FrogsLeap has left: Disconnected [15:09:34] --- jaltman/FrogsLeap has become available [15:31:17] --- deason/gmail has left [19:08:21] --- steven.jenkins has left [19:13:01] --- steven.jenkins has become available [20:24:26] --- mfelliott has become available [21:59:53] --- kaduk@mit.edu/barnowl has left [22:00:32] --- kaduk@mit.edu/barnowl has become available [22:59:08] --- lars.malinowsky has left [23:29:10] --- Russ has left: Disconnected