support for noatime
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.
Reply to: