[Gluster-users] Invalid atime with gluster-NFS
Niels de Vos
ndevos at redhat.com
Tue Dec 6 07:14:58 UTC 2016
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 at redhat.com> 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 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.
> >
> > 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
> >
More information about the Gluster-users
mailing list