3 ms·

Ideally, noatime would be the default, and applications that still care about atime would be updated to open with a new `O_ATIME` flag. Or, better yet, track it

Ideally, noatime would be the default, and applications that still care about atime would be updated to open with a new `O_ATIME` flag. Or, better yet, track it themselves independently. It's completely reasonable to turn it on. And also, when you're writing applications for Linux, consider using the `O_NOATIME` flag in your file opens.

lq9AJ8yrfs 1y ago
I think you're on to something, though it's optimistic to count on app devs to specify a novel platform-specific flag. "Don't break user-space" seems like it's in contest here. Maybe if you could taint a process (or perhaps the inode and/or path instead) so that its and its children's opens get the new o_atime flag by default, so that systemd or whatever could set it for legacy processes (or files/paths) that need it. Then distros or SRE's could put up with it without nagging all the SWEs about linuxisms. Some of whom may not know or care their code runs on linux.
mmh0000 1y ago
`relatime` is the default on many distros, and has long been "best-practice" for first pass Linux performance turning. MOUNT(8) relatime Update inode access times relative to modify or change time. Access time is only updated if the previous access time was earlier than or equal to the current modify or change time. (Similar to noatime, but it doesn’t break mutt(1) or other applications that need to know if a file has been read since the last time it was modified.) Since Linux 2.6.30, the kernel defaults to the behavior provided by this option (unless noatime was specified), and the strictatime option is required to obtain traditional semantics. In addition, since Linux 2.6.30, the file’s last access time is always updated if it is more than 1 day old.
- JoshTriplett 1y ago
  relatime is not as good as noatime, and it doesn't solve the problem reported in the article, since you can still easily end up with a large number of atime updates if you have a large number of files.

lq9AJ8yrfs 1y ago

I think you're on to something, though it's optimistic to count on app devs to specify a novel platform-specific flag. "Don't break user-space" seems like it's in contest here. Maybe if you could taint a process (or perhaps the inode and/or path instead) so that its and its children's opens get the new o_atime flag by default, so that systemd or whatever could set it for legacy processes (or files/paths) that need it. Then distros or SRE's could put up with it without nagging all the SWEs about linuxisms. Some of whom may not know or care their code runs on linux.

mmh0000 1y ago

`relatime` is the default on many distros, and has long been "best-practice" for first pass Linux performance turning. MOUNT(8) relatime Update inode access times relative to modify or change time. Access time is only updated if the previous access time was earlier than or equal to the current modify or change time. (Similar to noatime, but it doesn’t break mutt(1) or other applications that need to know if a file has been read since the last time it was modified.) Since Linux 2.6.30, the kernel defaults to the behavior provided by this option (unless noatime was specified), and the strictatime option is required to obtain traditional semantics. In addition, since Linux 2.6.30, the file’s last access time is always updated if it is more than 1 day old.

JoshTriplett 1y ago
relatime is not as good as noatime, and it doesn't solve the problem reported in the article, since you can still easily end up with a large number of atime updates if you have a large number of files.