I filed a bug and attached this proposed patch last week.
I have tested it with both gluster-NFS and Ganesha and it appears to fix the problem.
On Fri, Dec 2, 2016 at 10:19 PM, Niels de Vos <ndevos@xxxxxxxxxx> wrote:
Thanks for reporting this! Could you file a bug onOn Thu, Dec 01, 2016 at 05:04:06PM -0800, Eivind Sarto wrote:
> 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.
https://bugzilla.redhat.com/enter_bug.cgi?product= as well?GlusterFS
Just copy/paste the contents of the email in the report and let us know
the URL of the bug that you created. We'll clone the bug for all
actively maintained versions after that.
The attached patch has been completely untested, but it should resolve
the problem. I'd appreciate it if you can give that a try and report
results.
> 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.
NFS-Ganesha uses libgfapi and the library makes it possible to only pass
atime or mtime in glfs_h_setattrs(). Possibly NFS-Ganesha internally
maintains the atime+mtime combination, or the (Linux?) NFS-client
handles it differently over NFSv4. In any case, the attached patch
should also prevent this from happening with NFS-Ganesha.
> All other code in gluster, other than nfsserver, sets both ATIME and MTIME
> when doing an FOP_SETATTR.
Good to check that, it would give one possible explanation why this is
not happening over FUSE mounts.
Thanks again,
Niels
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
