<div dir="ltr">I filed a bug and attached this proposed patch last week.<div>I have tested it with both gluster-NFS and Ganesha and it appears to fix the problem.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 2, 2016 at 10:19 PM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Dec 01, 2016 at 05:04:06PM -0800, Eivind Sarto wrote:<br>
> Overwriting an existing file with O_TRUNC will yield an incorrect atime.<br>
> Example:<br>
><br>
> root@vsan123:~# cp /vmlinuz /nfs<br>
> root@vsan123:~# stat /nfs/vmlinuz<br>
> File: ‘/nfs/vmlinuz’<br>
> Size: 6565968 Blocks: 12825 IO Block: 1048576 regular file<br>
> Device: 25h/37d Inode: 10266595591654252930 Links: 1<br>
> Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)<br>
> Access: 2016-12-01 16:39:48.000000000 -0800<br>
> Modify: 2016-12-01 16:39:48.235275472 -0800<br>
> Change: 2016-12-01 16:39:48.239275472 -0800<br>
> Birth: -<br>
> root@vsan123:~# dd if=/vmlinuz of=/nfs/vmlinuz bs=64k conv=nocreat<br>
> 100+1 records in<br>
> 100+1 records out<br>
> 6565968 bytes (6.6 MB) copied, 0.0271412 s, 242 MB/s<br>
> root@vsan123:~# stat /nfs/vmlinuz<br>
> File: ‘/nfs/vmlinuz’<br>
> Size: 6565968 Blocks: 12825 IO Block: 1048576 regular file<br>
> Device: 25h/37d Inode: 10266595591654252930 Links: 1<br>
> Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)<br>
> Access: 1969-12-31 16:00:00.000000000 -0800<br>
> Modify: 2016-12-01 16:39:57.923275920 -0800<br>
> Change: 2016-12-01 16:39:57.923275920 -0800GF_SET_ATTR_MTIME<br>
> Birth: -<br>
><br>
> The Access time has been set to zero (or 1970 PST in my case)<br>
><br>
> This appears to happen in all versions of gluster. I think the problem can<br>
> actually be blamed on posix_setattr(). If one does a FOP_SETATTR and only<br>
> passes the GF_SET_ATTR_MTIME flag, posix_setattr() will blindly call<br>
> lutimes() to modify both atime+mtime and atime gets set to 0.<br>
> I think the solution would be to modify posix_setattr() to write back<br>
> original atime/mtime if one of the flags are not specified.<br>
<br>
</div></div>Thanks for reporting this! Could you file a bug on<br>
<a href="https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>enter_bug.cgi?product=<wbr>GlusterFS</a> as well?<br>
Just copy/paste the contents of the email in the report and let us know<br>
the URL of the bug that you created. We'll clone the bug for all<br>
actively maintained versions after that.<br>
<br>
The attached patch has been completely untested, but it should resolve<br>
the problem. I'd appreciate it if you can give that a try and report<br>
results.<br>
<span class=""><br>
> I have also seen NFS-Ganesha end up with a zero atime, but it does happen<br>
> not for the example above on Ganesha. Ganesha probably does something<br>
> similar someplace in its code where only GF_SET_ATTR_MTIME is being set.<br>
> But, I cannot remember exactly what caused the zero atime on Ganesha.<br>
<br>
</span>NFS-Ganesha uses libgfapi and the library makes it possible to only pass<br>
atime or mtime in glfs_h_setattrs(). Possibly NFS-Ganesha internally<br>
maintains the atime+mtime combination, or the (Linux?) NFS-client<br>
handles it differently over NFSv4. In any case, the attached patch<br>
should also prevent this from happening with NFS-Ganesha.<br>
<span class=""><br>
> All other code in gluster, other than nfsserver, sets both ATIME and MTIME<br>
> when doing an FOP_SETATTR.<br>
<br>
</span>Good to check that, it would give one possible explanation why this is<br>
not happening over FUSE mounts.<br>
<br>
Thanks again,<br>
Niels<br>
</blockquote></div><br></div>