tracker in F16

[Matthias Clasen]

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