[00:37:05] --- dev-zero@jabber.org has become available [00:38:42] --- dev-zero@jabber.org has left: offline [02:10:25] --- dev-zero@jabber.org has become available [02:10:28] --- dev-zero@jabber.org has left: offline [03:17:13] --- dev-zero@jabber.org has become available [03:18:55] --- dev-zero@jabber.org has left: offline [04:06:45] --- sxw has become available [04:19:15] --- sxw has left [05:26:38] --- SecureEndpoints has left: Replaced by new connection [05:37:05] --- dwbotsch has left [05:37:25] --- Rrrrred has become available [05:53:45] > server says that its bad has introduced a rather nasty busy loop in > the kernel. [05:54:12] there is some evidence from creedon that it can have that effect. so far i haven't tracked down the exact circumstance, because it's not all of them [07:03:47] --- reuteras has left [07:29:38] --- cclausen has left [07:30:41] --- mmeffie has become available [08:46:43] --- SecureEndpoints has become available [08:48:02] I have tried to reproduce the circumstance without success. I'm not sure what is Creedon is experiencing. [09:10:16] Here's an idea, which I'm ready to get shot down in flames ... [09:11:25] Our overhead on Linux is pretty significant, even for when a file is resident and up to date. I'm wondering if developing a mechansim which allows Linux to pass operations which are for chunk 0 of files which are up to date, and in the local cache, directly through to the filesystem which manages that local cache, might give us a significant speed boost. [09:11:38] Thoughts? [09:12:02] cache bypass? [09:12:24] We're not bypassing the cache, though. We're trying to use its data in a far more efficient fashion. [09:12:57] Or at least that would be my plan. Maybe I'm misunderstanding what you mean by "cache bypass?" [09:17:51] --- dev-zero@jabber.org has become available [09:17:51] --- dev-zero@jabber.org has left: offline [09:20:16] matt developed cache-bypass strategy a few yrs ago. [09:20:53] it's not quite what you're looking for, I don't think, but it's worth at least looking at for comparison/contrast purposes [09:20:58] I don't see how this relates to cache bypass though. I'm not interested in bypassing the cache, I want to get to data in the cache much faster (essentially, with fewer copies) [09:22:17] I'm not quite following what you're suggesting [09:22:32] The idea would be, for instance, that you get a readpage(). If that is for data contained in chunk 0 of a file that's in the cache, and up to date, then you open the cache file, and throw the entire readpage down to the inode handler for that cache file. [09:26:32] The problems that I can see immediately are that it would only work for disk cache, and that it breaks some of the kernel module abstraction layers (but they're pretty broken already) [09:30:22] yeah, definitely breaks abstraction. [10:38:59] --- Russ has become available [10:42:51] simon, it sounds like you want to do for Linux what the Windows afs redirector does. we memory map the cache files directly into the Windows File System cache via the Windows Memory Manager. All reads and writes are performed directly from the local file system. The AFS cache manager gets signalled when the contents of chunks are altered or no longer required; or when a chunk (extent in the Windows world) needs to be fetched. [10:48:51] --- dev-zero@jabber.org has become available [10:49:49] --- dev-zero@jabber.org has left: offline [10:51:49] Perhaps, but the architecture is rather different. [11:06:33] I don't think I'm looking to do something quite as invasive as moving towards the Windows CM model. [11:07:16] I'm just trying to think of ways of reducing the number of copies in the Unix CM for simple cases. Whilst we've still got the chunking storage model, how far that can be taken is somewhat limited. [11:08:21] My rationale for this, btw, is that we're moving our RPM slave servers over from using squid to AFS for RPM caching. And I'd really like the performance not to suck completely. [11:34:07] We do all of our system installs from RPM's in AFS. Well, all the Linux systems. [11:34:41] We actually modify the installer image so the {RPMS,Fedora,Packages} directory is a symlink into AFS, and then start an AFS client in a kickstart pre script. [11:35:00] (with disk cache on an ext2 ramdisk, IIRC) [11:35:06] --- mmeffie has left [13:03:57] --- sxw has become available [13:05:54] We use http for the final haul from server to client, and will probably continue to do that. What we're looking at changing is the way that the slaves and master store the RPMS, and transfer them internally (we did use a http server on the master, with squid on the slaves, we're now using AFS for the master, with a http server on each of the slaves to send to the clients) [13:09:50] hrm [13:10:00] I found that using AFS directly got pretty good performance, as long as you were careful to tune both the load and the cache parameters. For example, in the old days we set a large chunk size and then prepopulated the RPM header cache, to avoid touching the first few bytes of each RPM, which would have killed performance. [13:10:28] We have a separate header cache, anyways. [13:11:24] More recently, for F7 I wrote a new anaconda backend that skips all that pesky installing packages stuff and just extracts a compressed tarball. That cut install time in half. [13:12:09] Yeh. I think we're going to talk about something similar for RHEL6. We have our own local install technology currently, so we don't go near anaconda. [13:13:00] wonder when rhel6 comes out [13:13:23] sxw - are you mirroring the rpm repos on each client? [13:13:36] Nope. [13:13:49] Oh, you took that route. I've been hacking up anaconda to meet our needs for years. Once upon a time I actually rebuilt from source and constructed all the install media from scratch. These days, I only construct the boot media (including local kernel and modules), and use the updates mechanism to replace the modules I need to replace. [13:14:20] we have rpm yum repos in afs... and run yum update, up2date, and cfengine in the %post [13:14:54] ... and we've never actually used their "build system" for producing installers, because it's an unreproducible pile of crap that assumes you have all the packages and installer bits in place on the system you try to build the install media on. [13:14:59] I think we're going to take a look and see if anaconda can meet our needs for the next release. The major issue is that we don't want a depsolver getting involved - we want to be able to explicitly specify the EVR of every package that gets installed. [13:15:06] See /afs/cs.cmu.edu/misc/install/src/f7-install [13:16:53] R(r*)ed: We don't have a repository in each client. But we have enough clients that a single master can't handle them all. And we want to use http for the final haul to the client (it's a long story ...) [13:17:19] It's really hard to suppress that, which sucks because it takes a lot of unnecessary time when you know it's going to work. My approach has been to use some tools Chaskiel and I have hacked on over the years to figure out the dependencies (unfortunately, still not quite as automated as I'd like, but I went from a package list to one with no dependency failures in about a day this week), then feed the exact list to the installer. There are a couple of things you can't easily keep it from doing, like picking a kernel package, and you cannot force it to install a set with unresolved dependencies -- it'll generally add stuff to work around it. [13:17:54] for our needs... yum seems to work quite well [13:18:06] there are some bugs when dealing with the priority flag for repos, tho [13:18:14] For example, we really don't want the sendmail they ship, but there's all sorts of stuff that insists on having an mta, in no small part because the dependencies are overagressive. So we let it install sendmail, and then remove it --nodeps in a post script. [13:18:19] We have our own tool 'updaterpms' which takes a package list, and pushes it through RPM as a single transaction. [13:19:03] It then handles syncing new package lists from our configuration management system with the installed set. Makes keeping all of our client's package sets in perfect sync pretty simple. [13:19:08] yeah... I actually have a "doyum" script which looks through a bunch of files for various archs and hosts (add_rpms, remove_rpms, dont_up2date_rpms, dont_install_rpms, etc) and executes the appropriate yum commands [13:19:23] Oh, I might want to take a look at that at some point. I bet you could fairly easily write an anaconda backend to use that instead of the yum-based stuff they do now. I haven't really looked at what they've done to anaconda since F7, but by the workshop I should be intimately familiar with it again. [13:19:45] Speaking of which, when are you planning on arriving? [13:20:04] Arrive Saturday (late), depart Saturday (early), IIRC. [13:21:13] Actually, not too late: 16:36 at SFO. [13:23:51] Oh, you're arriving early. I don't arrive until late Sunday night, and depart Friday evening. [13:24:19] And that mostly because I figure I should be there Monday and Tuesday to talk to people and help with registration; it's not like I'm going to any tutorials. [13:25:15] I'm not going to any of the tutorials. [13:25:24] So what are you doing those days? [13:25:29] Basically, I'm on the cheapest flights our travel agent could find. [13:25:36] Killing time, I suspect. [13:25:54] I'm sure we can find things to talk about :-) [13:26:05] That was my feeling. [13:26:19] If git and gerrit aren't done by then, I may end up madly trying to finish those. [13:40:47] --- mmeffie has become available [13:59:06] --- dlc has become available [15:14:09] --- Rrrrred has left [15:14:44] --- dwbotsch has become available [15:28:51] --- mdionne has become available [15:36:07] --- mdionne has left [15:44:33] --- marc.c.dionne has become available [16:00:30] --- dlc has left [16:01:18] --- marc.c.dionne has left [16:03:44] --- dlc has become available [16:33:05] --- bpoliakoff has left [17:07:00] --- edgester has become available [18:16:25] --- mmeffie has left [19:46:16] --- edgester has left [21:24:08] --- Russ has left: Disconnected [21:43:31] --- Russ has become available [23:56:14] --- sxw has left