On Tue, 2011-09-20 at 10:46 +0200, Jürg Billeter wrote:
fanotify was delayed quite a bit, and we were told that there was nothing we can do to help and it was way too early to start experimenting with it for tracker. Now that it is in mainline, it would probably be easier to help out, but given that it took a long time for a kernel developer to get a subset of the planned features into mainline, I didn't attempt to work on the missing features myself so far.
Looks like the 'wait for the kernel to spontaneously grow the features we need' approach is not working great here. You should make your case for what you want to see in fanotify, and push for it.
We already use O_NOATIME in a few extractors, however, certain libraries don't make this very easy. Not even GIO allows to open a file for reading with O_NOATIME set, as far as I can tell. Also, I don't expect the amount of atime-related writes to be very high with relatime, but I haven't measured this and could be mistaken.
A GIO feature request for this has been filed ?
As a side-note, I myself would like to see more radical changes in how user files will be stored in the future. Ideally, we would stop storing them in traditional directory hierarchies. Among other things, this would completely avoid the need for recursive directory monitoring, recursive directory timestamps, and crawling on startup. On the downside, this would require changes in many applications, although FUSE could certainly help providing a compatibility layer. If anyone is interested in discussing or working on this, let me know.
I fear that this kind of 'radical' vision is not going to help making tracker successful in the short to medium term. I would really like to see tracker be successful in the use cases that it currently claims to cover before I would trust all my data to it...if ever.
Matthias