> On Dec 4, 2018, at 8:12 PM, Robert Elz <k...@munnari.oz.au> wrote:
>
> I'd probably change it more to be "do it when explicitly asked to,
> or whenever the inode is being updated for other reasons and an
> atime update could be made" - that is "unless instructed, don't do
> inode updates that update nothing but the atime", or IOW, "atime
> updates are not urgent and not required but are not prohibited".
Honestly, I think atime is one of the dumbest thing ever. But if one must
support it, then I think the following is a reasonable compromise:
-- If one is asked explicitly to set the atime by the user, then by all means,
go for it.
-- Implicit atime updates made by the file system should NEVER trigger an I/O,
but merely update the in-memory copy of the inode. If, for some reason, that
inode is pushed out to disk for some other reason, then by all means allow the
atime field to be updated at the same time.
If one has a need to have super-strict atime updates, then I think *that*
should be the optional behavior.
> That is, the purpose of noatime is to reduce I/O, not to hide the fact
> that files are being accessed (same with nodevmtime).
This is especially important with solid state drives. Those inode updates that
write less-than-a-NAND-chunk worth fragment the drive's translation tables,
which eventually leads to write amplification and reduced lifespan of the drive.
-- thorpej
