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