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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
