On Mon, Apr 04, 2005 at 07:59:42AM -0400, Dan Williams wrote: > 1) Get in to work > 2) boot laptop > 3) run yum update > 4) updatedb starts during rpm transaction > 5) Wait until updatedb finishes before rpm transaction can continue > > Step 5 takes a really really long time. Obviously, both are hitting the disk > quite a bit. the real problem here is that rpm does a lot of synchronous IO, which isn't quite "normal" IO. In normal IO patterns, the VM writes back a bunch of cached writes (either because of memory pressure or after 30 seconds). Such write backs are asynchronous which means that a bunch of them will get queued up independent of one of them finishing, and nothing will block and wait until those IOs are finished. The rpm synchronized IO case means that rpm will submit one, small, IO and then wait for that to complete before it continues. In the async case, the kernel has a lot of room for optimizing and making things well behaved. In the synchronous case *any* amount of delay is 100% directly noticable. And that sucks. > Is there any way to detect how much disk activity has gone on in > the last 5 minutes, for example, and not start updatedb until its settled down? well that is certainly not hard, the problem comes when updatedb notices itself running ;) > It seems that cron could benefit from additional constraints on starting jobs, > for example postponing a job until cpu and/or disk activity reaches a certain > level, whether on battery or not, etc. Would these be useful modifications? it's anacron not cron that does this, and in this case I'd actually just modify updatedb to do this not cron. But that's a matter of taste... And there needs to be an upper limit on how long it waits for a quiet time otherwise a mildly loaded server would never run updatedb at all