Atime and btrfs: a bad combination?
Posted Jun 1, 2012 4:30 UTC (Fri) by jzbiciak
(✭ supporter ✭
Parent article: Atime and btrfs: a bad combination?
I seem to recall posting a crazy idea about moving atime out to its own separately managed data structure and keeping it out of the inode entirely. (I can't find the comment now, of course.)
But still... atime is broken. It turns reads into writes and is generally just nasty. Furthermore, most things just don't need it.
Here's a totally radical, unsellable idea:
- Disable all atime updates by default everywhere.
- Add an extended attribute saying "do atime updates on this file only" (or relatime, if you so choose).
- For systems that truly need accurate atime everywhere: Create a new mechanism that all filesystems can use just for storing atime. Create a backing store that is highly optimized for atime updates and nothing else. Provide an option to roll atime updates into the filesystem if necessary, but in most cases, allow this parallel structure to manage atime. Everyone else that doesn't need atime updates can ignore that kludgy thing.
Even in the absence of that crazy idea, it still sounds like having atime in the inode allows for trivial bandwidth and storage-size amplification attacks. If you could factor out atime updates to some dedicated on-disk structure that relied more on versioning semantics than COW, you could at least fix btrfs' immediate problem without totally ditching atime. With 8 byte atime and 8 byte inode numbers (let's say), The 2.2GB quoted in the article is enough space to store 128M atime updates if they were stored like a journal.
to post comments)