[Gluster-users] Invalid atime with gluster-NFS

[Eivind Sarto]

Overwriting an existing file with O_TRUNC will yield an incorrect atime.
Example:

root at vsan123:~# cp /vmlinuz /nfs
root at 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 at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20161201/83d17623/attachment.html>