Overwriting an existing file with O_TRUNC will yield an incorrect atime.
Example:
root@vsan123:~# cp /vmlinuz /nfs
root@vsan123:~# stat /nfs/vmlinuz
File: ‘/nfs/vmlinuz’
Size: 6565968 Blocks: 12825 IO Block: 1048576 regular file
Device: 25h/37d Inode: 10266595591654252930 Links: 1
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2016-12-01 16:39:48.000000000 -0800
Modify: 2016-12-01 16:39:48.235275472 -0800
Change: 2016-12-01 16:39:48.239275472 -0800
Birth: -
root@vsan123:~# dd if=/vmlinuz of=/nfs/vmlinuz bs=64k conv=nocreat
100+1 records in
100+1 records out
6565968 bytes (6.6 MB) copied, 0.0271412 s, 242 MB/s
root@vsan123:~# stat /nfs/vmlinuz
File: ‘/nfs/vmlinuz’
Size: 6565968 Blocks: 12825 IO Block: 1048576 regular file
Device: 25h/37d Inode: 10266595591654252930 Links: 1
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 1969-12-31 16:00:00.000000000 -0800
Modify: 2016-12-01 16:39:57.923275920 -0800
Change: 2016-12-01 16:39:57.923275920 -0800GF_SET_ATTR_MTIME
Birth: -
The Access time has been set to zero (or 1970 PST in my case)
This appears to happen in all versions of gluster. I think the problem can actually be blamed on posix_setattr(). If one does a FOP_SETATTR and only passes the GF_SET_ATTR_MTIME flag, posix_setattr() will blindly call lutimes() to modify both atime+mtime and atime gets set to 0.
I think the solution would be to modify posix_setattr() to write back original atime/mtime if one of the flags are not specified.
I have also seen NFS-Ganesha end up with a zero atime, but it does happen not for the example above on Ganesha. Ganesha probably does something similar someplace in its code where only GF_SET_ATTR_MTIME is being set. But, I cannot remember exactly what caused the zero atime on Ganesha.
All other code in gluster, other than nfsserver, sets both ATIME and MTIME when doing an FOP_SETATTR.
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
