rlocate vs. mlocate

[Nathan Grennan]

>>  It sounds like someone still needs to write a inotify version of
>> locate. I have no problem with a light weight daemon that would just
>> reindex the locate database based on information feed to it by the
>> kernel via inotify.
>>     
> I'm not an inotify expert, nevertheless I think there are two "gritty
> programming details" to solve.  First, inotify doesn't work over network
> filesystems, so it isn't possible to guarantee instantaneous update in
> general, and a periodic scan is necessary anyway.  Second, inodes of all
> watched directories have to be kept in memory; on my laptop that would
> be roughly 16000 inodes, which is about 10 MB of memory wasted for
> locate; consider a file server with a few terabytes of storage.  (To
> prevent this pinning of kernel memory, inotify has a configurable limit
> on the number of watches, which is 8192 by default.)
>
>   
  I see 10mb as nothing, so much more than that gets wasted on others 
stuff. As for terabytes, people could disable it, or may also have 
gigabytes of memory.
>> It would be an almost instantaneous replacement for
>> both find and locate.
>>     
> No, find(1) is specified by SUSv3, which explicitly states "The find
> utility shall recursively descend the directory hierarchy...".  Because
> other programs can detect whether find(1) was traversing the subtree, we
> can't optimize it out.
>
>   
  I am not sure I quite agree with SUSv3 on this point, or even your 
interpretation of it, but even if it can't be changed, we could make 
another command with the same syntax that instead just hits the database.
> In my experience the file is not moving in these cases, but that's of
> course not a statistically relevant sample
  It isn't about the file moving, it is about not remembering where the 
file is located and wanting a quick search. Though things do move with 
time. Especially when you update packages and their is a new maintainer.