rlocate vs. mlocate

[Miloslav Trmac]

Nathan Grennan napsal(a):
> I would say as expected the focus is too much in the gritty
> programming details, and not the big picture which tends to be a common
> problem.
Sometimes it turns out the great "big picture" is unimplementable
because of a "gritty programing detail" :)

>  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.)

> 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.

> where as most of the time you just need
> to find the file by name, especially as root.
In my experience the file is not moving in these cases, but that's of
course not a statistically relevant sample.
	Mirek