atime changes when mtime changed on NFSv3 mount

[Peter Edwards]

I noticed the atime on a file changes when the mtime is changed on a Isilon NFSv3 mount, seen on RHEL6 (2.6.32-431.11.2.el6) and RHEL5 (2.6.18-371.6.1.el5), on RHEL6 the mount is mounted with the default relatime option.  This behaviour differs to local filesystems and to NetApp NFSv3 mounts (on RHEL6 both also mounted with relatime).  I am wondering why this is, here is a reproducer where the mtime is changed using touch and the atime also changes:

touch -d '1985-11-04 19:53:20' /path/b ; ls -lu --time-style full-iso /path/b ; touch -m -d '1985-11-04 19:53:21' /path/b ; ls -lu --time-style full-iso /path/b
-rw-r--r-- 1 user group 0 1985-11-04 19:53:20.000000000 -0500 /path/b
-rw-r--r-- 1 user group 0 1985-11-04 19:53:21.000000000 -0500 /path/b

compared to a local filesystem where the atime does not change:

 

touch -d '1985-11-04 19:53:20' /tmp/b ; ls -lu --time-style full-iso /tmp/b ; touch -m -d '1985-11-04 19:53:21' /tmp/b ; ls -lu --time-style full-iso /tmp/b

-rw-r--r-- 1 user group 0 1985-11-04 19:53:20.000000000 -0500 /tmp/b

-rw-r--r-- 1 user group 0 1985-11-04 19:53:20.000000000 -0500 /tmp/b

 

An strace on the touch shows the same arguments and return code from the utimensat system call:

 

strace -e trace=utimensat touch -d '1985-11-04 19:53:20' <file>

utimensat(0, NULL, {{500000000, 0}, {500000000, 0}}, 0) = 0

 

strace -e trace=utimensat touch -m -d '1985-11-04 19:53:21' <file>

utimensat(0, NULL, {{500000000, 0}, {500000001, 0}}, 0) = 0

Any insight welcome.  Thanks.

[Peter Edwards]

I found:

  http://marc.info/?l=linux-nfs&m=138989348317051&w=2

which mentions:

 

"In particular, the

  atime / noatime ,

  diratime / nodiratime ,

  relatime / norelatime ,

and

  strictatime / nostrictatime

mount options have no effect on NFS mounts.

  /proc/mounts

may report that the

  relatime

mount option is set on NFS mounts, but in fact the

  atime

semantics are always as described here, and are not like

  relatime

semantics."

 

So the "relatime" mount option I see in /proc/mounts is a red herring.

[Peter Serocka]

On 2014 Jul 31, at 24:58, Peter Edwards <thatsaf...@gmail.com> wrote:
> So the "relatime" mount option I see in /proc/mounts is a red herring.

It would be difficult to imagine how with NFS the
client-side mount options should interact
with the server-side mount options for the
underlying file system, be it ifs or ext3/4 or xfs or…

The other question is, upon what type of
“file access” the atime stamp is supposed to be
updated: just reads, or any access in the broadest
sense, including writes, permission changes etc.
Afaik this hasn’t been specified too clearly,
so file systems have a certain freedom of choice.

At the same time, atime stamps have been
widely considered to be bad idea in the first place
[ ] ;-)
[ ] :(

> --
> You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Peter Edwards]

For what it is worth RFC 1813 contains:

 

  "The atime and mtime fields can be set to either

   the server's current time or a time supplied by the

   client."

 

  "Atime is the time when the file data

   was last accessed."

 

and RFC 1094 contains:

 

  " "atime" is the

   time when the file was last accessed for either read or write"

 

but given I am using nfs on linux and this patch - http://marc.info/?l=linux-nfs&m=138989348317051&w=2.

 

It seems best to skip any tests that depend on atime behaviour if the filesystem is NFS on linux.

In particular the itch I am scratching is t/io/fs.t from perl which fails on Isilon NFSv3 because it does not expect

the atime to be updated when the mtime is set.