On Wed, 2005-04-20 at 03:09 -0400, Mike A. Harris wrote: > There are many possible solutions in theory. > > [...] > > - Perhaps alter updatedb's script to use iorenice to lower it's > I/O priority and improve interactivity? Not sure if this would > actually result in the desired behaviour or not, but I'm sure > one of our kernel guys can advise wether this would truly help > or not. This was already discussed in some detail here -- it's not necessarily IO scheduling that's the problem here. In fact, now that CFQ is back as the default elevator, I hardly notice updatedb running. The bigger problem I think is the swapout is causes. Let updatedb do its run, then switch to another application and notice the delay as it's swapped back in. There was actually an interesting lkml discussion[1] about this. It was suggested that /proc/sys/vm/swappiness be decreased when running updatedb. Does this kill babies? > - Turn updatedb into a daemon which updates the database by using > fam/gamin to get directory notification events. Not sure how > feasible or crackrock this might be, but it popped into my mind, > and if it is feasible, and any problems it might have could be > worked out, might make locate even more useful. There were some suggestions for using inotify. However, inotify doesn't support recursive directory watching, so using it for every directory would have a high memory impact. The author advised against using it for monitoring the entire tree (Beagle for example uses it for the home directory only). dnotify on the other hand would quickly run out of file descriptors. > I'm sure others might have additional suggestions. Feel free > to comment on mine. Well, I have a hunch that updatedb is not doing things in a very efficient way (it doesn't seem to be using knowledge of the underlying file system). But running time is the least of our worries here. [1] http://kerneltrap.org/node/3000 -- Ziga