Atime and btrfs: a bad combination?

Posted Jun 3, 2012 10:19 UTC (Sun) by ballombe (subscriber, #9523)
In reply to: Atime and btrfs: a bad combination? by liljencrantz
Parent article: Atime and btrfs: a bad combination?

I note that nowhere in your post are you suggesting an alternative, so basically you are arguing that popcon should not have been written at all.

Atime and btrfs: a bad combination?

Posted Jun 3, 2012 11:00 UTC (Sun) by liljencrantz (guest, #28458) [Link] (1 responses)

I'm suggesting that the usefulness of popcon is smaller than the damage of atime, so even if there is no alternative implementation strategy for popcon, it would still be better to drop atime.

Atime and btrfs: a bad combination?

Posted Jun 3, 2012 14:57 UTC (Sun) by Yorick (guest, #19241) [Link]

Quite right—for every odd feature there will always be someone having found a use for it and object to it being taken away. But the cost of its existence is often carried by everyone: in performance, code complexity, security, ease of use, conceptual simplicity, and so on. For atime, it should stand clear that the occasional benefits stand in no proportion to those costs.

We see this every time a sensible proposal comes forth to dump an old misfeature that causes way more grief than enjoyment. Control characters in file names, for example...

Atime and btrfs: a bad combination?

Posted Jun 3, 2012 19:48 UTC (Sun) by nybble41 (subscriber, #55106) [Link]

Wouldn't the audit interface offer one alternative? It's already used for tracking file accesses for readahead optimization.

The downside, of course, would be that some daemon would have to run in the background to collect the audit data. However, that could still involve less overhead than updating atimes on every filesystem read.