solving(?) the updatedb problem w/ the kernel cache

[Douglas J Hunley <doug@hunley.homeip.net>]

I've been following lkml for a little while (not understanding it all, but 
following nonetheless <g>) and I've noticed that in a lot of the talks about 
schedulers, elevators, and performance, the issue of running updatedb and its 
effects on the kernel's fs cache seems to recur. I've also yet to see anyone 
present a solution that others think is worth pursuing. I'm curious why we're 
trying to solve the problem, when we can simply avoid the problem to begin 
with by making use of inotify and introducing a new user-space 
daemon, 'located'. 

This daemon would be started by the init scripts, register one or more inotify 
listeners based on /etc/updatedb.conf and then go to sleep. Whenever the fs 
is modified, an inotify event is triggered and 'located' wakes up, 
adjusts 'locate.db', and then goes back to sleep. It's about as simple as a 
daemon can get and still be of use, I think.

Add a little 'configure' foo to detect if the system has inotify support and 
if it does, build/install the new daemon. If it doesn't, then don't build it 
and use the old behavior. With the daemon up and running, you can rm the 
updatedb entry in cron.daily and the negative impact it causes on the 
kernel's fs simply goes away. 

You wouldn't need to modify 'locate' itself, as it would still read 
from 'locate.db' like it does now. As an added bonus, you'd now have 
real-time results from 'locate'. If your Sys Admin just 
installed /usr/bin/foo, then 'locate foo' would find it "immediately". No 
more waiting until the next run of 'updatedb' for accurate results.

All the major distros support inotify at this point, I believe. If I could 
code, I'd have attached the daemon here myself :)

I must admit, though, I'm a little perplexed why greater minds than mine 
haven't already implemented this. I must be missing some technical issue. Can 
anyone enlighten me on the same?
-- 
Douglas J Hunley (doug at hunley.homeip.net)