Re: [Tracker] [Re: tracker in F16]

[Aleksander Morgado <aleksander lanedo com>]

Hey Lennart,

> > a) tracker uses inotify recursively and creates a massive number of
> > watches due to that. That is both ugly and doesn't scale. Tracker
> > apparently tries to not take up the full pool of inotfy handles the
> > system provides, but that won't help if you have more than one user on
> > the system. The solution here should probably be fanotify, which allows
> > proper recursive file system watches. So far fanotify has been
> > accessible to root only, which is presumably why tracker doesn't use
> > it. However, the solution here cannot be to work around that fact by
> > using inotify, but must be to invest the necessary kernel work to make
> > fanotify useful from unprivileged processes. 

AFAIK, fanotify is not a direct replacement of inotify feature-wise. For
example, with fanotify we lose the ability to match move events, as with
the FD that we get we can only know the new path, not the old one. Move
events are very handy to avoid re-indexing a whole directory tree when
its moved to another location. So it is not only that we gain recursive
watches with fanotify, I guess we need to put all pros and cons in the
balance and check whether it's really worth to use it as it is now, or
try to update it with new features we may need. From my personal use
case (personal PC, only one user, default configuration), I never hit
the limit of inotify watches (8192 in my setup), and crawling just to
add monitors takes almost nothing, so inotify even if not perfect, is
not that bad.

For reference on this issue, Alexander Larsson took a look at fanotify
some time ago with file indexers in mind and wrote an email to the LKML
about it, which also includes some nice-to-have features in filesystem
monitoring systems:
https://lkml.org/lkml/2009/3/27/166

Cheers,

-- 
Aleksander