Re: noatime mounts inhibiting atime updates via utime()

[Jason Thorpe <thorpej%me.com@localhost>]

> On Dec 4, 2018, at 8:12 PM, Robert Elz <kre%munnari.OZ.AU@localhost> 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