There is now an implementation of a system-wide filesystem monitor using fanotify:

​http://www.piware.de/2012/02/fatrace-report-system-wide-file-access-events/

Eric Paris <eparis@redhat.com> wrote:

It could, although fanotify doesn't have good (really any?) handling of mv.  I've been thinking about how to handle those but haven't had the time to try to code something, and I'm sure that the VFS people are going to give me a really rough time of it.

An fanotify listener can easily listen for all modify events and record what needs to be later re-indexed.  Heck, I could probably code that in less than 200 lines (>50% of something like that code is in the lkml posting).

But I think you would still need to traverse the whole fs regularly to look for moves, which might defeat the purpose.....

I just haven't figured out a reasonable way to indicate mv.  I probably should spend some time looking what other OS's do....

Paul Wise <pabs3@bonedaddy.net> wrote:

Do you mind if I copy this to the bug report?

I definitely think mv notifications are needed, some of the links I posted in the bug report might help you design them.

Eric Paris <eparis@redhat.com> wrote:

Feel free to say anything I say, although I just realized the ONLY thing that matters for updatedb is move, so really all I told you is "I can't do that right now"

I started looking at move tonight, I know I could do something on
sys_rename but I don't see how to do notification if an inode is moved by say the nfsd server instead of by a sys_call.  I'll try to talk to the VFS maintainer and see if he has some thoughts.....

I believe fsnotify will allow this:

http://lwn.net/Articles/311850/

If it doesn't, contacting the fsnotify/fanotify author and asking for the feature might be a good idea.

For inotify it appears that Linux allows the number of watches to be increased (see the -r option) when the user is root:

http://manpages.debian.net/man/1/inotifywatch

Other kernels have similar things:

http://en.wikipedia.org/wiki/FSEvents
http://www.opengroup.org/onlinepubs/9657099/
http://msdn.microsoft.com/en-us/library/aa365261(VS.85).aspx

It might be a good idea to look at FAM and gamin to find out how to do this on various kernels:

http://en.wikipedia.org/wiki/File_alteration_monitor
http://en.wikipedia.org/wiki/Gamin

It would be nice to not have to run updatedb every night, causing large I/O bandwidth reading every filename off the disk. One way to achieve this would be locate-d, a daemon which would listen to kernel-emitted filesystem events (from dnotify, inotify or fsnotify for Linux) and then update the database at a configurable interval. By storing timestamps of the events in the database, information about the evolution of the filesystem over time could be obtained. locate could be modified to query this daemon before checking the database. Such a feature (along with fixing the other issues fixed by other implementations) could make GNU findutils the default locate implementation on most GNU/Linux distros again.