[01:38:47] --- sxw has become available [02:39:38] --- manfred has become available [02:46:48] --- sxw has left [03:41:47] --- SecureEndpoints has left: Replaced by new connection [04:02:36] --- SecureEndpoints has become available [04:46:40] --- SecureEndpoints has left [05:01:48] --- SecureEndpoints has become available [05:32:32] --- manfred has left [05:46:49] --- SecureEndpoints has left [05:55:07] --- SecureEndpoints has become available [06:44:08] --- matt has become available [06:47:08] (starking somewhat) > MR AFS clients were proprietary only..and they're gone now. It's better not to make assumptions like that, no matter how true you're sure they are. The available RPC space is _huge_ -- 4 million distinct procedures -- so there is no need to "reclaim" numbers. Even the pioctl space is large enough to make it not worth the effort. [06:47:43] --- dmontuori has become available [06:48:47] Mail to registrar goes into an RT queue, which currently only I read. Kula is theoretically a registrar, but we haven't spun up any of the stuff needed so he can actually do anything. That's on my todo list for sometime in the very near future, as its a prereq to putting Simon's proposal for standardization into effect. [06:51:58] > the registrar's published documents are out of date. Yes, they are. When assigning numbers, I look at the published documents, plus the requests still in the RT queue for which I have issued numbers but not updated the published documents, plus the OpenAFS source code. [06:53:17] --- summatusmentis has become available [06:54:30] Jeff, if you haven't asked IBM to nominate a registrar, please do so. If you have, please let me know what answer you got, if any. [06:55:46] shadow: thanks for killing rt 18206 [07:38:24] --- reuteras has left [07:51:53] Jeff, IBM was asked and there has been no response. I am not expecting one until IBM makes up its mind as to what it wants to do about the trademark. [07:54:56] trademark means using "AFS" right? Not something more seriously code related? [07:56:59] Trademarks are branding. IBM owns the mark "AFS" when used in the field of computer software. That has an impact on the use of related marks "OpenAFS", "kAFS", "TurboAFS", "BionicAFS", etc. [07:58:26] right, ok. That's annoying [07:58:43] I personally do not believe that IBM's lawyers could win a trademark suit against anyone over the use of the "AFS" mark. However, none of us can afford to pay the lawyers to fight such a suit. Therefore, IBM wins by fiat. [07:59:48] yeh [08:07:08] Yeah, OK. I didn't expect they had answered, but I wanted to be sure. We can proceed without them. [08:08:27] jhutz - wrt pioctls for Rx OSD. Feel free to say 'no; here are new ones', and I can go from there. [08:18:13] Yeah, OK [08:19:54] --- manfred has become available [08:32:54] --- abo has left [09:29:00] --- Simon Wilkinson has left [09:43:26] --- dev-zero@jabber.org has left [09:50:41] --- Simon Wilkinson has become available [10:01:16] --- Russ has become available [10:47:14] --- manfred has left [10:51:49] --- Simon Wilkinson has left [10:52:33] --- stevenjenkins has left [11:00:43] --- stevenjenkins has become available [11:20:05] --- Simon Wilkinson has become available [11:20:34] --- Simon Wilkinson has left [11:20:39] --- Simon Wilkinson has become available [11:20:41] --- dev-zero@jabber.org has become available [11:22:53] Anyone around, or are you all busy partying? [11:23:17] I wasn't invited to the Capitol :-( [11:23:21] in a mtg. [11:23:23] :( [11:23:26] buy my parents are there [11:23:31] but [11:23:38] here [11:23:46] Okay. That's enough to ask. [11:24:02] Wondering what the feeling would be about a 1.5 only change that gets rid of LINUX_USE_FH [11:24:28] Basically, the idea would be that an 'inode' in a buffer or a dcache becomes an abstract type, that only the chunkops layer (mem or ufs) knows how to interpret. [11:24:33] just uses it? [11:24:46] sorry, not parsing that. [11:24:50] probably a good idea. [11:24:55] we're moving in that direction anyway [11:25:09] It would make the code a lot cleaner, and makes it a lot easier to implement other per-OS inode types. [11:25:41] The only issue I can see is that we'd need to pass inodes around by reference, so platforms on which they are a single byte type would take a reference, dereference hit every time one is used. [11:25:54] But, I don't see that as a big performance penalty. [11:26:25] i'm trying to worry. i'm not managing to [11:26:39] Cool. I'll finish up my patch, and send it through. [11:27:05] Turns out that disconnected can build a userland OpenAFS, and resync it, providing the network you're on doesn't suck. [11:27:10] So, thats a good thing ... [11:27:54] nice [11:28:07] yay [11:29:32] Better performance on sucky networks is this evenings task - basically if a server gets marked down during reconnection, it never gets marked back up again (because CheckServers is disabled, as we're still disconnected). So, I'm just going to mark everything up at the start of each pass. [12:06:07] Interesting ... centos are shipping kernels in their 'centosplus' repository with native AFS support enabled ... [12:08:34] i wonder how up-to-date it is [12:14:27] kafs? [12:14:34] yes [12:22:13] I suspect it will just be whatever is in that Linux kernel, but turned on. It does say (read only) in the document I found. [12:31:30] Can we kill the links to the autogenerated pages for the RedHat / Fedora distributions, and just point people at the download directories? I'm getting bored of people going "but there isn't a kernel module for X", when its just because the HTML pages are out of date. [12:32:22] sorry [12:33:00] the right answer is to somehow autorun the script nightly and commit the result [12:33:21] it's not your fault. Just wondering if the simplest solution would be just to not use those pages. [12:34:31] regenerated [12:35:19] ta. [12:35:37] Is the problem with running it nightly getting the right credentials in place, or are there other issues? [12:35:53] --- dmontuori has left [12:35:59] --- dmontuori has become available [12:36:38] "grand is a poc" and "it needs a frontend script to give the right arguments", probably, before, and now only the latter [12:59:02] --- dmontuori has left [12:59:35] the hard timeout for a volserver transaction is..10 minutes? [13:10:34] the volserver sets the RxDeadTime to 7 minutes. vos dump and vos size use 10 minutes. [13:14:25] tx; I saw the 10 mins in GCTrans(), but there is a refCount check in there as well, so I'm not clear on how long an active (but slow) transaction can continue. [13:20:26] --- dmontuori has become available [13:20:32] well, if the call goes away while the transaction is active, it times out in 10 minutes. a progressing transaction which is going slow or will take a long time can continue indefinitely [13:21:23] tx; that's how I'm reading the code as well, but I didn't know if there was yet something else that might be mucking w/refCount like GCTrans(). [13:23:29] An active transaction can go on forever. [13:23:49] There is no "hard timeout" [13:23:50] fwiw, at 2am, I was thinking about Chaz's low-bandwidth site issue -- a vos release or move of a volume is going to be painful: 1M per minute is really rough. I can't imagine trying to move a user volume of a 100M or so and that taking almost 2 hrs. [13:23:54] jhutz - tx. [13:24:12] i can [13:24:17] so can I [13:24:27] i did releases over a 38.4 modem [13:24:31] ok. I *can* image it. But I would not look forward to it. [13:24:40] err, s/image/imagine/ [13:24:53] When operations take that long, you structure your work differently [13:25:30] * stevenjenkins nods. yes, I used AFS over a modem as well..but that was back when disk costs were high, so storage space was at a premium. [13:25:39] jhutz - yep. very true. [14:02:37] --- manfred has become available [14:07:02] We used to do volume moves that would take hours. It's not as big of a deal as it sounds. [14:07:19] It's not ideal, but it's not really that bad, as long as you don't lose network connectivity in the middle. Then it sucks. [14:07:29] We still do. Yesterday my backup system did a dump that took 17 hours. [14:08:43] (it was a 100GB volume, and would probably have finished considerably sooner if the backup machine wasn't also running other dumps, several in parallel, for much of that time) [14:17:14] I'm going to need victims (sorry, testers) for all of the cache managers I can't easily test - that's everything that's not Linux, Darwin and Solaris. Do we know people that can be leaned on to do this? [14:20:20] i can test aix 6 and irix. i no longer have any hpux. [14:21:32] Cool. There's two things I want to get tested before I go. The first is this inode abstraction thing I'm doing now. The other is moving all of the vcache attributes that we want to save to disk into their own structure. [14:23:42] ok [14:26:20] BTW, the LINUX_USE_FH changes would have completely broken systems running with memory caches - they stopped preserving the contents of f.inode. [14:26:33] s/would have/do/ [14:29:13] --- SecureEndpoints has left [14:49:51] --- SecureEndpoints has become available [15:06:13] --- SecureEndpoints has left [15:08:42] --- mdionne has become available [15:14:40] Re: LINUX_USE_FH - if you read the original ticket (123620), I presented it as an RFC/Proof of concept. I agree that generalizing the interface away from just inodes is the way to go [15:16:05] Going forward for Linux, we should choose a single method, either open by file path or by file handle [15:18:17] --- manfred has left [15:35:55] --- SecureEndpoints has become available [15:45:57] --- dmontuori has left [15:53:33] mdionne: Judging from the can of worms I'm opening, your solution was great for 1.4 [15:54:20] Moving away from the idea that an inode is just a number breaks a couple of things - the memory cache for one (although I'm using a union for afs_inode_t to fix that), and also the IHINT code. [15:54:41] Does anyone know if IHINT has ever actually been used? It's conditional, and I can't see anything that would enable it. [15:57:25] If I recall from looking at the code, I couldn't see anything that used IHINT [16:00:06] and yes, I realize that the code is not compatible with memory cache [16:00:51] the idea was to allow testing of the new interface with minimal impact to existing code when it was not enabled [16:00:53] It would be great if you could review the changes I'm thinking of making. [16:01:22] i'd be glad to have a look [16:01:26] In fact, it would be great if you wouldn't mind reviewing all of the Linux cache manager changes that I'm doing. I do feel like a bit of a bull in a china shop. [16:01:47] I can post a link to a patch here, when its done, or is email better? [16:02:46] Either is OK - I can also do some testing if you need it [16:10:49] what I don't like in the current interface is that the "inode" number has different meanings: regular inodes, mem cache slots or magic numbers to generate file names [16:13:09] sxw: I'd be happy to look at xbsd, when you're at that point. [16:16:05] --- matt has left [16:19:05] --- matt has become available [16:19:09] --- matt has left [16:21:20] mdionne: Indeed. What I've done is make an afs_inode_t a union - so you can have a number (for mem cache), and anything you like for UFS in the same space. [16:22:23] I suspect that if open by path works on Darwin, we should possibly consider killing the magic number code, in favour of a persistent by-path interface on all platforms (we've got it for Linux and Solaris already) [16:33:00] but open by path has issues on linux, at least as far as I tested it. I think that use of lookup from another filesystem is not an expected usage, and there seems to bel locking issues [16:40:25] the current Linux code in 1.5 and 1.4 does not use open by path, despite the rumors.. :) It uses file handles in a simple way that assumes the underlying file system understands inode handles - treus for ext2 and ext3 [16:40:45] treus -> true [17:04:15] Ah. Okay. I obviously haven't stared enough at that pieces of code ... [18:13:51] --- mdionne has left [18:23:05] --- Russ has left: Disconnected [18:46:13] --- Russ has become available [20:32:53] --- dev-zero@jabber.org has left [20:42:01] --- dev-zero@jabber.org has become available [21:06:14] --- dlc has left [21:14:19] --- dev-zero@jabber.org has left [21:21:52] --- dev-zero@jabber.org has become available [21:21:56] --- Simon Wilkinson has left [21:26:14] --- SecureEndpoints has left: Replaced by new connection [22:03:51] --- Russ has left: Disconnected [22:12:26] --- dev-zero@jabber.org has left [22:42:50] --- dev-zero@jabber.org has become available [23:04:56] --- reuteras has become available [23:52:14] --- reuteras has left [23:53:32] --- manfred has become available