Atime and btrfs: a bad combination?

Posted Jun 1, 2012 19:20 UTC (Fri) by ballombe (subscriber, #9523)
Parent article: Atime and btrfs: a bad combination?

Atime is used by popularity-contest (popcon.debian.org) to find packages that were recently used. It seems the least intrusive option. It is sad to see it being deprecated without better alternative being provided.

Atime and btrfs: a bad combination?

Posted Jun 2, 2012 7:49 UTC (Sat) by liljencrantz (guest, #28458) [Link] (5 responses)

Quite the contrary, atime is horribly bad idea that should never have been allowed to survive the seventies. Converting most reads into a read and a write is such an obviously horrible idea that one should not even have to argue about it - it just needs to go away.

As such, I think it's extremely sad to see that relatively modern software, like popcon, is *still* being written that makes the misguided mistake of using this feature.

Atime and btrfs: a bad combination?

Posted Jun 3, 2012 10:19 UTC (Sun) by ballombe (subscriber, #9523) [Link] (3 responses)

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.

Atime and btrfs: a bad combination?

Posted Jun 5, 2012 9:31 UTC (Tue) by zack (subscriber, #7062) [Link]

> Converting most reads into a read and a write is such an obviously horrible idea that one should not even have to argue about it

The "converting reads into write" argument is very nice (and lyric), but it's not particularly compelling. atime is not changing the intrinsic nature of reads. atime is a logging/accounting mechanism like many others that an OS kernel implements. It is in the nature of accounting to consume space and that happens (inevitably) also when you log actions that, per se, wouldn't have consumed any space. I don't see any inherent flaw in that, it is "just" a matter of difficult trade-offs about where to store the information and how to minimize their size when space is tight.