Oi you lot! Let's identify issues related to noatime. Thanks to hard work by Ted Ts'o and others, there's relatively little reason to use noatime on your average ext4-using amd64 desktop/laptop/server. There's a performance penalty but because of relatime and lazytime[1] it's pretty minor.
But there are reasons other than performance. For example, on any filesystem that allows CoW snapshots (btrfs, zfs, anything in a CoWed virtual machine, etc), every update of atime causes a CoW break, forcing allocation and rewrite of a chunk typically much larger than just the inode. This was first noticed in https://lwn.net/Articles/499297/, I've tested other filesystems on that same kind of data (/usr-y stuff), the cost is usually on the order of 5%. Per snapshot. As a good majority of use cases I hear about do snapshots daily, which is also same as the frequency of a typical cronjob that would dirty atimes, we're talking about doubling disk usage per 20 days for no useful gain. This cost might be less if your cronjob just stats every file rather than reading it, but roughly 1 in 12 inodes is a directory[2] and thus still will be affected. I guess most users won't expect ENOSPC on something they think of as a purely read action. Thus, after we discuss this, I'd recommend d-i guys to make noatime the default on btrfs and zfs. Another case are SoCs on SD and eMMC cards. I haven't done any research there but at least all SoC images I've got (raspbian, Odroid-U2, PINE64) use noatime for all partitions. So, let's list what can break. * mbox files and new mail notifications. This one could be fixed by explicit atime updates (see below). Should I go on a patching spree? * tmpreaper. Using mtime instead of atime might be acceptable, might break something but tmpreaper is already in the "scary warnings, can break stuff" land. I use tmpreaper -m without explosions for years but I've no untrusted users. * popcon "vote" field. Most of us look at "installed" anyway. * some forensic tools? Please tell me what I missed. For mbox files (and possibly similar cases), there's only a handful of interested readers, thus they can be patched to touch atime by hand instead of relying on a system-wide mount option. Ie, read() and friends would be accompanied by: struct timespec times[2]={{0,UTIME_NOW},{0,UTIME_OMIT}}; futimens(f, times); (no need for making this conditional, it's redundant but harmless without noatime, and the inode update will be cached -- no one sane mounts /var with -osync). Such an explicit atime update is currently restricted to root and the file's owner. I wonder if there's an use case for atime updates by a no-owner; I can't currently think of one but I have a strong hunch I'm missing something. This would need to be done in the kernel: https://github.com/kilobyte/linux/commit/dc49d7588dd64afedec2d1ab6d6ebab28dfc51a4 As kernel plans have changed (4.9 rather than 4.10 is rumoured to be the LTS), I'd need to pester Al Viro now if this change is to hit stretch. Meow! [1]. Lazytime is advertised as a replacement for relatime, but you really want both. And lazytime affects mtime as well. [2]. On ~ten real machines doing vastly different tasks, the min file:directory ratio was 11:1, the max 13:1. -- An imaginary friend squared is a real enemy.
