On Wed, Jan 10, 2024 at 12:44 PM Lyndon Nerenberg (VE7TFX/VE6BBM) <lyn...@orthanc.ca> wrote: > > Olivier Certner writes: > > > I've never found any compelling reason in most uses to enable "atime", > > except > > perhaps local mail but as addressed in other answers it is a relic of the > > pa > > st mostly irrelevant today. And its drawbacks are well known and can be > > seri > > ous. > > When UNIX ran on PDP-11s and disk pack sizes were measured in the > tens of megabytes, atime was very helpful in determining which files > were likely candidates for archiving to tape when the disk was > getting full. And in the Usenet days it was common to mount > /var/spool/news noatime, which eliminated a *lot* of meta-info > write traffic. > > These days, other than /var/mail, I can't think of a compelling use > for it. I've been running my Plan 9 systems with atime disabled > ever since fossil arrived (decades) without any impact. > > I don't see any issue with making noatime the default. For those > that must have it, /var/mail can be carved out as a distinct > filesystem and mounted appropriately. Just choosing the last message in the thread... I do not have a strong opinion w.r.t. atime, but I do believe that changing the default would be a POLA violation.
Please look at this email thread, where the opinion w.r.t. atime seemed quite different: freebsd-hackers@ Oct. 5, 2023 Subject: copy_file_range() doesn't update the atime of an empty file I'd put a url here, but gmail always puts the subject line in here when I copy/paste the url? Basically I did not think that updating the infd's atime when copy_file_range() did not actually copy any data, but the collective disagreed, so I patched the NFSv4 client. (I do not know if markj@'s patch did get committed). They also collectively thought that Linux did a poor job w.r.t. atime. rick > > --lyndon >
