Wandering Thoughts archives

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

It all started with this tweet by Matt Simmons which led to a mailing list question and a second message with context:

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 (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.