Just updated from 10.2 to 11.0-RELEASE-p8, also happens on 10.2 and 10.3. Accessing ZFS filesystem via nfs4 from CentOS 6.5 and 7.3 clients. When using cp the resulting file has an access time in the far future. On CentOs 6.5 client accessing the file produces a reasonable access time, but not on CentOS 7.3. Centos 5.6 does not have the issue at all. jim@sunnyvale$echo "test" > foo jim@sunnyvale$ls -l --time=atime total 7 -rw-r--r-- 1 jim etguest 5 Mar 29 15:23 foo jim@sunnyvale$/bin/cp foo foo2 jim@sunnyvale$ls -l --time=atime total 13 -rw-r--r-- 1 jim etguest 5 Mar 29 15:23 foo -rw-r--r-- 1 jim etguest 5 Jan 4 2091 foo2 jim@sunnyvale$cat foo2 > /dev/null jim@sunnyvale$ls -l --time=atime total 13 -rw-r--r-- 1 jim etguest 5 Mar 29 15:23 foo -rw-r--r-- 1 jim etguest 5 Mar 29 15:23 foo2 jim@sunnyvale$/bin/cp foo foo3 jim@sunnyvale$ls -l --time=atime total 14 -rw-r--r-- 1 jim etguest 5 Mar 29 15:23 foo -rw-r--r-- 1 jim etguest 5 Mar 29 15:23 foo2 -rw-r--r-- 1 jim etguest 5 Jan 5 2091 foo3 Note that on the server the time is in the far past rather than the far future: root@adrastea:/foo/test # ls -l -u total 20 -rw-r--r-- 1 14522 1014 5 Mar 29 15:23 foo -rw-r--r-- 1 14522 1014 5 Mar 29 15:23 foo2 -rw-r--r-- 1 14522 1014 5 Nov 30 1954 foo3 Options shown in /proc/mounts on the CentOS 6.5 client are nfs4 rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=130.126.120.168,minorversion=0,local_lock=none,addr=130.126.120.98 0 0
I have no idea what it means, but if I saw this and the mount had something called "relatime" as a mount option, I would suspect that. If you can mount without the "relatime" (whatever that does) and see if the problem persists, I would suggest trying that. rick
From https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Power_Management_Guide/Relatime.html "relatime maintains atime data, but not for each time that a file is accessed. With this option enabled, atime data is written to the disk only if the file has been modified since the atime data was last updated (mtime), or if the file was last accessed more than a certain amount of time ago (by default, one day)." By mounting with -o norelatime,strictatime I was able to make the relatime option disappear from /proc/mounts, but the future atime issue is unchanged. The issue is only the initial atime setting when the file is created. It just seems to get stuck in the future after that.
Well, if you capture a packet trace for the failing case (new create) via "# tcpdump -s 0 -w out.pcap host <nfs-client-host>" on the server and then emailing me out.pcap, I can take a look at it in about a week. Since the atime would normally be specified by the client, I won't guess why it ends up 2091?? rick
Commit r317236 in head/current fixes this and will be MFC'd in 2 weeks. Thanks go to Jim for reporting this and testing the patch.
Patch has been MFC'd.