== Things get weird with read-only NFS mounts and atime on Linux

It all started with [[this tweet by Matt Simmons
https://twitter.com/standaloneSA/status/408587006248505345]] which
led to [[a mailing list question
http://www.bblisa.org/pipermail/bblisa/2013-December/003668.html]]
and [[a second message with context
http://www.bblisa.org/pipermail/bblisa/2013-December/003670.html]]:

> Nevertheless, I tested it and unless I messed up my test, an NFS mount
> with -o ro, you read a file on the mounted FS, and the access time is
> updated.
>
> For the test the server was a NetApp, the client was Linux.
>
> There is a mount flag -o noatime that does what I want. But I would
> argue that this is not right. The simplest behavior - nothing is ever
> written period - should be what you get by default, and then there
> could be a flag that enables exceptional behavior, that is updating
> the access time.

Actually things here are much more interesting and odd than you
might think. In light of the fact that [[mounting the filesystem
_ro_ on the client doesn't quite mean what you might think on NFS
../unix/NFSReadonlyLevels]] (and how atime works on NFS), the ordinary
behavior makes complete sense. It's not that the client is sending atime
updates to the server despite the NFS mount being read-only, it's that
the server is updating atimes when the client does reads. The weird
thing is what seems to happen when the *client* mounts the filesystem
with _noatime_.

(The server mounting the filesystem with _noatime_ should turn off atime
updates regardless of what the setting is on your client.)

It turns out that this is an illusion. As a stateless protocol, NFS
servers do not send any sort of notification to clients when a file's
attributes change; instead NFS clients have to check for this by issuing
a NFS _GETATTR_ operation every time they need to know. Because a
Unix system looks at file attributes quite frequently, NFS clients
normally keep caches of recent enough _GETATTR_ results and expire
them periodically. On Linux, when you mount a NFS filesystem without
_noatime_ the NFS client code decides that you really want to know about
atime updates and so it often deliberately bypasses this _GETATTR_ cache
so it can pull in the latest atime update from the server. When you
mount the same NFS filesystem with _noatime_ this special bypass doesn't
happen and you get the full attribute cache effects, which means that
you don't see server updates to atime until the cache entry for your
file expires (or is invalidated for some reason, or is evicted).

(Attribute caching is covered in the _nfs(5)_ manpage; see the
description of _ac_, _actimeo_, and so on.)

So what's really happening here is that with a _noatime_ NFS mount the
atime is still being updated on the server but you won't see that update
on your client for some amount of time (how long depends on various
things). If you check the atime immediately after reading from a file,
this will look like the atime isn't being updated at all. You could see
the true state of affairs by looking at the atime on either the server
or on another client that was mounting the filesystem without _noatime_.

The corollary of this is that ~~mounting your NFS filesystems with
_noatime_ will reduce the number of NFS requests you make to the
server~~ (although I don't know by how much). In some situations this
may be a quite useful feature, especially if you've already turned off
atime updates on the server itself.