Atime and btrfs: a bad combination?

Posted Jun 1, 2012 7:53 UTC (Fri) by MrWim (subscriber, #47432)
In reply to: Atime and btrfs: a bad combination? by jzbiciak
Parent article: Atime and btrfs: a bad combination?

Interesting. It seems to me that the infrastructure for this already exists so for any particular use case this could be implemented in userspace using inotify and the flag IN_ACCESS. Presumably tmpwatch and tmpreaper could use a mechanism like this listening for files in tmp (tmpwatchd?) or perhaps a daemon could be written which you could use to request atime like information be collected for a particular directory heirarchy. There would be the potential that mutt could use the same mechanism.

One nice property about this solution is that reads being writes are now explicit and if disk runs out read isn't going to fail but the failure mode can be implemented in the watching daemon.

Potentially you could take the dconf like design where a convenient atime API is provided such that atime can be read synchronously by mapping the atime "database" into the process that is reading it read-only whereas the atimed process would be the only process with write access to this file.

Atime and btrfs: a bad combination?

Posted Jun 1, 2012 12:45 UTC (Fri) by ablock (guest, #84933) [Link]

I really like that idea. This would allow linux to completely get rid of atime in the filesystem code, or at least to default mount with noatime.

Atime and btrfs: a bad combination?

Posted Jun 1, 2012 13:13 UTC (Fri) by jzbiciak (guest, #5246) [Link] (2 responses)

Of course, here's where it breaks: How do you export that over NFS? I guess nfsd would also need to talk to that infrastructure also.

My suggestion about doing it at the kernel level is that you retain the userspace ABI, and there's never an application that breaks because you've radically changed where atime gets monitored and recorded.

I guess you could provide a FUSE-like mechanism to hook userspace back up to 'stat'.

Atime and btrfs: a bad combination?

Posted Jun 3, 2012 22:39 UTC (Sun) by MrWim (subscriber, #47432) [Link] (1 responses)

To export it over NFS you would just export the atime database over NFS. The daemon would only run on the server and clients would (read-only) access the database file directly. This would work just as well as the local case (i.e. well if your applications are atimed aware and not at all for non-atimed aware apps which care about atime).

As you say a FUSE filesystem could be offered to preserve the stat() interface but it would probably be less work to get the existing apps which use atime to use some new library. The only examples I ever hear of are tmpwatch and mutt.

Atime and btrfs: a bad combination?

Posted Jun 7, 2012 12:29 UTC (Thu) by MrWim (subscriber, #47432) [Link]

On second thought this is probably way more complicated than it needs to be. In particular this generic atimed approach introduces a whole bunch of synchronization complexity. It would probably be easier to patch mutt to update atime explicitly and introduce a bespoke tmpwatchd explicitly for the /tmp case.