On Mon, 4 Apr 2005, Arjan van de Ven wrote: > On Mon, 2005-04-04 at 04:42 -0400, Alan Cox wrote: > > On Sun, Apr 03, 2005 at 09:05:37PM -0400, Richard Hally wrote: > > > are you saying that Fedora is unsuitable for ordinary desktops and (by > > > extension laptops) unless they have scsi? > > > > I think some people would prefer to say that "PC's are unsuitable for use > > without real disks" 8) > > > > In this case the fact that it is I/O not CPU means the requirements to quieten > > such an app are really not handled by nice(2) > > also note that the cfq io scheduler makes updatedb and friends a lot > more bareable. CFQ is default in our kernel, but not in kernel.org > kernels, so if the "2.6 is bad with updatedb" notion is based on > kernel.org kernels then I strongly suggest switching those to CFQ. Even with Red Hat kernels, this really sucks: 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. 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? 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? Dan