5 ms·

> More trivia: if you mount your filesystem readonly, it is technically not POSIX compliant any more because the atimes won't be updated Isn't POSIX fun?

mprovost 6y ago
atime doesn't quite work because it makes a read operation into a write. Mostly that's ok, because you're just overwriting the same timestamp field over and over again. But it gets strange with filesystem snapshots or anything else that might be copy on write. Now your reads end up using disk space as it has to make a copy of each directory to update the atime - if it is in fact doing that. Traditionally, reading a snapshot just didn't update the atime (but then does the snapshot keep the atime as it was at the time of the snapshot, and reading files in the live filesystem means making a copy?). This means, as was pointed out, snapshots aren't POSIX compliant.
- formerly_proven 6y ago
  atime isn't updated on every access. That "relatime" mount option that's almost universally used? It updates atime when the file is written (so mtime and ctime are updated anyway, no extra cost to bumping atime), or after a day if no writes happen but reads.
- jsrcout 6y ago
  > atime doesn't quite work because it makes a read operation into a write. I remember discovering this little fact a lot of years ago. It really shook my confidence in the existence of a rational world. Then I learned about noatime and never looked back.
Spivak 6y ago
This really isn't that weird. Imagine you had auditing requirements for a SQL database that you must know when the last time each row was accessed. But in this universe the SQL database is your only persistent datastore (because machines might only have one partition and your system must still function when there is only one partition) so you have to store access times in the rows. But your SQL server only has two modes, the whole database is read-only or the whole database is read-write. You really wish there was a soft read-only where only the auditing data is allowed to be updated but it doesn't exit. So now you're stuck with read-only replicas of your database being noncomplaint. It's a problem that really has no good solution outside of the filesystem driver supporting this mode.
JdeBP 6y ago
Erroneous descriptions of it are, certainly. The Single Unix Specification explicitly requires this effect of read-only mounts. * https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_09 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
paulddraper 6y ago
atime is the biggest misfeature ever. Turning every read into a write......there are very few cases that would be preferrable for.

mprovost 6y ago

atime doesn't quite work because it makes a read operation into a write. Mostly that's ok, because you're just overwriting the same timestamp field over and over again. But it gets strange with filesystem snapshots or anything else that might be copy on write. Now your reads end up using disk space as it has to make a copy of each directory to update the atime - if it is in fact doing that. Traditionally, reading a snapshot just didn't update the atime (but then does the snapshot keep the atime as it was at the time of the snapshot, and reading files in the live filesystem means making a copy?). This means, as was pointed out, snapshots aren't POSIX compliant.

formerly_proven 6y ago
atime isn't updated on every access. That "relatime" mount option that's almost universally used? It updates atime when the file is written (so mtime and ctime are updated anyway, no extra cost to bumping atime), or after a day if no writes happen but reads.
jsrcout 6y ago
> atime doesn't quite work because it makes a read operation into a write. I remember discovering this little fact a lot of years ago. It really shook my confidence in the existence of a rational world. Then I learned about noatime and never looked back.

Spivak 6y ago

This really isn't that weird. Imagine you had auditing requirements for a SQL database that you must know when the last time each row was accessed. But in this universe the SQL database is your only persistent datastore (because machines might only have one partition and your system must still function when there is only one partition) so you have to store access times in the rows. But your SQL server only has two modes, the whole database is read-only or the whole database is read-write. You really wish there was a soft read-only where only the auditing data is allowed to be updated but it doesn't exit. So now you're stuck with read-only replicas of your database being noncomplaint. It's a problem that really has no good solution outside of the filesystem driver supporting this mode.

JdeBP 6y ago

Erroneous descriptions of it are, certainly. The Single Unix Specification explicitly requires this effect of read-only mounts. * https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_09 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

paulddraper 6y ago

atime is the biggest misfeature ever. Turning every read into a write......there are very few cases that would be preferrable for.