On Mon, Dec 05, 2016 at 09:46:10AM -0800, Eivind Sarto wrote: > 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. Thanks, I found the bug with patch you filed: https://bugzilla.redhat.com/show_bug.cgi?id=1401122 We use Gerrit at https://review.gluster.org/ for patch submission and review. The development process requires patches to be sent against the master branch before they can get included/backported to the stable releases. I have posted your patch, and updated it a little with fixes for the comments I have. please have a look and provide any comments you have: http://review.gluster.org/#/c/16034/1..4/xlators/storage/posix/src/posix.c We will include the change through https://bugzilla.redhat.com/1401777 first. Once that is done, we can take the patch and includ it in the stable branches. Niels > On Fri, Dec 2, 2016 at 10:19 PM, Niels de Vos <ndevos@xxxxxxxxxx> wrote: > > > On 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. > > > > Thanks for reporting this! Could you file a bug on > > https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS as well? > > 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
