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 _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
