[00:09:06] --- dev-zero@jabber.org has left [01:11:32] --- dragos.tatulea has become available [01:11:38] gooooood morning [01:26:28] --- dev-zero@jabber.org has become available [01:52:31] --- dragos.tatulea has left [02:11:18] --- haba has become available [02:11:33] good lunch (or equiv) [02:35:36] --- Simon Wilkinson has become available [03:19:23] --- manfred furuholmen has left [03:42:25] --- manfred furuholmen has become available [03:48:27] --- manfred furuholmen has left [04:02:05] --- dev-zero@jabber.org has left [04:11:53] --- dev-zero@jabber.org has become available [04:20:37] --- haba has left [04:28:16] --- Simon Wilkinson has left [04:29:58] --- Simon Wilkinson has become available [04:35:03] --- floh has left [05:16:13] > acell->linkedCell is now pointed at freed memory. [05:16:26] hey, it's just pointers. so it's free-by-reference right? ;) [05:25:37] --- haba has become available [05:25:49] --- haba has left [05:25:53] --- haba has become available [05:58:11] Do I need to write code for the following operation sequence: 1 Lock a volume so that it can not be altered by some client. Break all callbacks. 2 Do things to the volume (restore, salvage, whatever). 3 Unlock and break callbacks on the volume. [06:04:51] --- matt has become available [06:07:30] * haba on the train from Uppsala to Stockholm (3G most of the time with the phone hanging from its USB cable in the window) [06:08:30] hi harald [06:12:19] hi matt [06:13:34] --- haba has left [06:22:16] there's no lock a volume operation [06:22:29] like, not really. you can take it offline. [06:23:01] though if you'e doing that, breaking callbacks at 1) is stupid [07:07:28] --- dmontuori has become available [07:14:10] --- summatusmentis has left [07:20:12] --- haba has become available [07:30:31] Ok, breaking CB at 3) allready does "someone else did modify", you loose. But it may be better to get that earlier or not? [07:31:41] * haba should get to bed because of cold (*cough*) but that's not fun either. [08:29:25] --- RedBear has left [08:46:41] --- Simon Wilkinson has left [08:49:01] --- Moose has become available [08:49:19] haba! [08:54:26] --- cg2v has become available [09:03:31] --- dwbotsch has become available [09:12:12] --- reuteras has left [09:23:41] --- Russ has become available [09:26:11] --- Brandon Allbery has become available [09:26:28] --- dev-zero@jabber.org has left [09:30:10] --- Brandon Allbery has left [09:32:22] --- Brandon Allbery has become available [09:39:55] --- Brandon Allbery has left [09:42:46] --- Brandon Allbery has become available [09:51:38] --- Brandon Allbery has left [09:53:23] --- Brandon Allbery has become available [10:00:03] --- Brandon Allbery has left [10:00:59] --- Brandon Allbery has become available [10:07:47] --- summatusmentis has become available [10:09:20] --- dmontuori has left [10:10:05] --- dmontuori has become available [10:23:11] anyone have a bad volume (ie, one that needs salvaging) yet that can be attached? [10:23:28] I need to test something, and having that condition would be helpful. [10:24:00] --- haba has left [10:24:01] --- haba has become available [10:25:02] --- Brandon Allbery has left [10:28:17] --- Brandon Allbery has become available [10:39:49] --- summatusmentis has left [10:56:15] --- dev-zero@jabber.org has become available [10:59:18] --- tkeiser@sinenomine.net/owl has left [11:03:58] --- tkeiser@sinenomine.net/owl has become available [11:04:53] --- summatusmentis has become available [11:11:52] --- Simon Wilkinson has become available [11:25:33] --- mmeffie has left [11:31:50] --- summatusmentis has left [11:38:41] --- Simon Wilkinson has left [11:42:43] I have an almost-working vos split pulled out of rx osd.. [11:43:03] a few little wrinkles to address, and one user-interface issue. [11:43:11] hartmut assumes people will provide vnodes.. [11:43:26] it seems to me that a -path is a much more natural approach [11:43:42] ie, not everyone that would use this will want to run whatfid to find out the vnode in question. [11:43:49] agree/disagree/don'tcare? [11:44:56] --- jhutz@jis.mit.edu/owl has left: Lost connection [11:44:56] --- jhutz@jis.mit.edu/owl has become available [11:44:56] --- jhutz@jis.mit.edu/owl has left: Lost connection [11:48:39] --- Brandon Allbery has left [11:49:14] --- summatusmentis has become available [11:51:59] --- Brandon Allbery has become available [11:54:15] --- Brandon Allbery has left [11:56:06] --- Brandon Allbery has become available [11:56:45] sjenkins: both? [11:56:48] right. [11:57:08] the -vnode would one would useful for some types of programmatic things, but the -path version would be better for most people (I think) [11:59:43] --- summatusmentis has left [12:01:38] --- haba has left [12:13:22] --- summatusmentis has become available [12:31:59] --- dev-zero@jabber.org has left: Replaced by new connection [12:31:59] --- dev-zero@jabber.org has become available [12:39:55] "vos split"? [12:40:27] It's an awesome idea. It turns a volume into multiple volumes. It was part of Hartmut's giant patch set, IIRC. [12:40:49] yow [12:40:57] steve simmons is sitting here drooling over it [12:41:35] heck, I'm drooling too [12:41:39] heh [12:41:49] We have custom scripts to do that operation that are tricky and annoying and have outage windows. [12:42:23] steve keeps talking about making a custom script to do it. amusingly, when he started talking to me about what he wanted said script to do, i had to stop him and say, "Have you heard of 'up'?" [12:42:27] he hadn't :) [12:42:51] I need to get a cell up [12:44:04] it's really really hard [12:44:08] your eyes will bleed [12:44:11] your brain will melt [12:44:30] monkeys will fly out of your but [12:44:32] I set one up over the summer, but I should get one up with multiple servers, and learn the commands, what they do, etc. [12:44:34] butt [12:48:10] I'd rather not have monkeys flying out of my butt :( [12:48:45] vos create -nomonkeys [12:50:34] bos create localhost -instance monkeys [12:51:05] Isn't that bos create butt -instance monkeys -type flying ? :) [12:51:12] oh yeah [12:51:26] but only in the wicked-witch cell [13:07:02] --- manfred furuholmen has become available [13:13:22] --- cg2v has left [13:14:22] --- summatusmentis has left [13:19:00] --- SecureEndpoints has left [13:25:13] delayed. stupid terminal screwage equals i didn't see messages til now. yes, vos split by path would be more natural. but vos doesn't have dependency on pioctl. or know paths. [13:32:49] --- SecureEndpoints has become available [13:38:05] --- dmontuori has left [13:38:11] --- dmontuori has become available [13:42:07] --- mmeffie has become available [13:47:32] --- dmontuori has left [13:47:38] --- dmontuori has become available [13:50:09] so don't add that dependency? [13:50:30] I can just make sure to document it well in the man page [13:50:40] and possibly provide a little wrapper script [13:54:32] volumes do not exist at absolute paths. I would be happier with an interface that allowed the relative path in the volume to be specified where the FID for that path would be determined by executing an RPC instead of querying the cache manager. [13:55:11] I don't think vos commands should be dependent on a cache manager in order for them to be implemented [13:58:01] wrt vos commands not depending on a cache manager: agreed. [13:58:41] wrt interface into relative paths: how would that be done w/o a cache manager? (or at least linking in some of the cm<->fs RPCs) [13:58:56] --- Brandon Allbery has left [13:59:26] I wouldn't use the cm<->fs RPCs [13:59:39] add new RPCs? [13:59:47] that is what I suggested [14:00:01] what process is on each end? vos <-> ??? [14:00:35] the vos split command issues an RPC that splits the volume, correct? [14:00:40] correct [14:01:01] then the server side of the RPC should evaluate the relative path and perform the split [14:01:13] --- Brandon Allbery has become available [14:01:19] the server has full access to the volume [14:01:43] why does the client even have to been involved in figuring out what FID the path evaluates to? [14:01:53] s/been/be [14:01:54] so pass the path to the volserver. [14:02:00] ie, the relative path [14:02:00] that is what I would do [14:02:09] there's no "an RPC" to do it yet, you get to walk the path. [14:02:40] damn, behind again [14:02:44] wrt 'why does the client even have to be involved...': the existing code uses a vnode. [14:02:44] yep [14:02:56] it doesn't need to [14:02:56] so don't use the existing code [14:03:09] I thought that interface a bit awkward, hence the questions here. [14:03:15] * stevenjenkins nods. [14:03:15] if you don't like how it works, you've already committed to changing it. [14:03:20] heh [14:03:25] tx shadow. [14:03:28] you have now convinced me not to accept the existing code [14:03:34] exactly [14:04:08] that's fine, btw. the whole reason I raised it is that the interface is awkward, and looking to either 1- validate that or 2- invalidate that. [14:04:38] so I'll look into adding the ability to do relative paths into the volume as well. [14:04:59] :) [14:05:19] --- Simon Wilkinson has become available [14:05:27] if someone has suggestions as to the interface for that 'RelPathToVnode' RPC (name, parameters, etc), I'd appreciate the input. [14:05:38] I'm not sure where else it would be useful, so I don't know how generic to make it. [14:07:58] Just remember to include afs3-standardization in the discussion if you're going to be adding new RPCs. [14:08:03] --- Brandon Allbery has left [14:08:12] it needs to take a volume id and a path in that volume, and return a fid. for this you only care about directories but it should support more than that. it should only be available to admins, for simplicity [14:08:41] steven, you are missing the point. There is no need for a RelPathToVnode RPC. [14:09:02] there's no need for one, sure, the "split" rpc can take a path [14:09:23] but there will be other things that want to do the path to vnode, so properly an interface might be useful [14:09:40] the volserver is the entity performing the split. Pass the relpath to the volserver in the VL_SplitVolume RPC. The volserver should figure it out. [14:09:42] tho we have an interesting question. how are we handling afs3-stds for hartmut's code? [14:10:20] --- Brandon Allbery has become available [14:10:24] In "Simon's ideal world", Hartmut, or whoever is shepherding getting that code into AFS should write a protocol document that describes all of the changes in it. [14:10:33] yep [14:11:11] Making the maximum amount of work might not be ideal. [14:11:23] That's not the maximum amount of work. [14:11:38] that is actually the minimum necessary to document the extension [14:11:43] The maximum amount of work is if there are glaring problems at the protocol level exposed by review of the protocol documetnation. [14:11:55] bingo! [14:12:00] Then we have to rewrite it. That's the maximum amount of work, and I hope that won't happen. [14:12:11] argh, jeff's stuff is coming out in dark green on grey, it's unreadable [14:12:26] But, I can't see how we can do a reasonable level of review without looking at the protocol on its own. [14:13:38] --- dmontuori has left [14:13:45] --- dmontuori has become available [14:15:09] That's going to be the problem with all of the big changes we've got pending. Do we 'grandfather' them in, without any protocol discussion (and make life so much harder when we come to document the 'base' protocol), or do we require protocol documentation before we accept them. [14:15:33] I'm firmly in favour of the latter. If you want your changes in OpenAFS, you need to work with us in producing the documentation we require. [14:17:02] Hartmut has produced quite a lot of slides, starting in 2006, I think? It might be late to approach him with that. There may well be problems exposed by review, but I doubt the perspective we're working from is to avoid incorporating rxosd. [14:17:05] we already know that rxosd has a protocol conflict with other changes that were implemented for . I don't think the volume versioning change was accepted into the openafs repository [14:17:36] so the question becomes, which one do you want more? [14:17:45] or who will be burned? [14:17:55] the problem is with hartmut sort of half-retired getting him to do it likely won't work well, but he's best equipped to do so [14:18:04] really i wish he'd talked to people in the first place [14:18:29] Perhaps if someone offers to work with Hartmut on it? So the bulk of the work isn't being done by him, but he can review and correct as appropriate. [14:18:41] hartmut is willing to work on openafs [14:19:10] i bet if we could find someone or some way to pay him he'd be happy to do it, but alas i am not the cash fairy [14:19:22] And why not? [14:19:46] born with wrong last name to wrong parents [14:20:17] Yeh gods. High School Musical has just finished in the Main House of the theatre I'm currently in. About to suffer an avalanche of small children high on chocolate and Disney show tunes. [14:20:32] hahahahaha [14:21:19] i think i need to get some food. [14:21:59] Back later. [14:22:21] --- Simon Wilkinson has left [14:25:45] --- dmontuori has left [14:28:30] we were alluding to [14:28:32] + if (astat->SyncCounter != tvp->updateDate) { [14:28:33] ? [14:52:26] that would be the one [15:24:43] --- manfred furuholmen has left [15:42:40] --- edgester has become available [15:59:56] --- Moose has left [16:46:17] --- emacbeth13 has become available [16:46:59] --- emacbeth13 has left [17:20:43] --- Russ has left: Disconnected [17:52:33] --- matt has left [18:18:23] I wonder where the new CellServDB file is [18:31:33] oh there it is [19:33:48] --- Brandon Allbery has left [19:35:56] --- Brandon Allbery has become available [19:39:23] --- Brandon Allbery has left [19:39:25] wrt rx osd, etc -- I'm happy to spend as much time as I can helping get that done/integrated, but I haven't had any serious talk w/hartmut about it. Also, I need to balance rx osd w/other stuff (ie, work). [19:39:43] (and I won't be online much this weekend, but I'll review the logs Sun night when I get back) [19:41:34] --- Brandon Allbery has become available [19:48:51] --- Brandon Allbery has left [19:50:10] --- Brandon Allbery has become available [20:00:41] --- Brandon Allbery has left [20:02:46] --- Brandon Allbery has become available [20:05:08] --- edgester has left [21:04:00] --- Rrrrred has left [21:06:29] --- RedZBear has become available [21:18:21] --- Brandon Allbery has left [21:20:22] --- Brandon Allbery has become available [21:33:31] --- Brandon Allbery has left [21:34:58] --- Brandon Allbery has become available [22:07:03] --- Brandon Allbery has left [22:09:04] --- Brandon Allbery has become available [22:20:46] --- summatusmentis has become available [22:24:44] --- summatusmentis has left