Atime and btrfs: a bad combination?

Posted Jun 1, 2012 13:13 UTC (Fri) by jzbiciak (guest, #5246)
In reply to: Atime and btrfs: a bad combination? by MrWim
Parent article: Atime and btrfs: a bad combination?

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.