On Sun, Sep 6, 2020 at 3:00 AM Roberto Ragusa <mail@xxxxxxxxxxxxxxxx> wrote: > I've found atime useful in several cases. If you are doubting about a configuration file being > read or not by an application, you just check the atime before and after running it > (way easier than strace). If you are investigating what a suspect script or confused user > has just done, you can find for recent atime. Sure, but for that to be reliable, you need 'atime'. You're changing the default anyway. fatrace? auditctl watch? inotify IN_ACCESS? > After it took years to go back from noatime to a weak relatime, we are now going to > lose it completely again. atime/relatime make read-only operations into ones that write. Possibly quite a lot of writes. Does it make sense for everyone to have it enabled by default everywhere? Is that on-going cost worth some regular benefit? > Did any filesystem developer ever think about storing atime in a different way, instead > of usual inode metadata? Maybe a dedicated journal of overriding atime entries > (column based DB vs inode's row based DB) to cope with "access many files" > patterns. Yes. > And what happened to "lazytime"? It sounded like a great approach. Lazytime is a better default than relatime. But it just delays the inevitable, because it updates the on-disk metadata once every 24 hours. So it doesn't solve the problem under discussion. Are atime updates generally useful? For most files, most users, most of the time? If not, the default should be noatime. And programs that need this information should use inotify. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
