Bug 1422075

Summary:	GlusterFS truncates nanoseconds to microseconds when setting mtime
Product:	[Community] GlusterFS	Reporter:	Niels de Vos <ndevos>
Component:	core	Assignee:	bugs <bugs>
Status:	CLOSED EOL	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.10	CC:	bugs, ndevos, nh2-redhatbugzilla, pkarampu, rabhat
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1422074	Environment:
Last Closed:	2018-06-20 18:26:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1422074
Bug Blocks:

Description Niels de Vos 2017-02-14 12:27:45 UTC

+++ This bug was initially created as a clone of Bug #1422074 +++

+++ This bug was initially created as a clone of Bug #1419733 +++

Description of problem:

Programs that set mtime, such as `rsync -a`, don't work correctly on GlusterFS, because it sets the nanoseconds to 000.

This creates problems for incremental backups, where files get accidentally copied again and again.

For example, consider `myfile` on an ext4 system, being copied to a GlusterFS volume, with `rsync -a` and then `cp -u` in turn. You'd expect that after the first `rsync -a`, `cp -u` agrees that the file need not be copied.

$ cp -u -v myfile /mnt
'myfile' -> '/mnt/myfile'
$ cp -u -v myfile /mnt
$ rsync -a myfile /mnt
$ cp -u -v myfile /mnt
'myfile' -> '/mnt/myfile'

It copied it again!

Version-Release number of selected component (if applicable):
3.9.1

How reproducible:
Always


Steps to Reproduce:

With gluster mounted on /mnt:

1. rm -f /mnt/myfile && touch /mnt/file
2. # now `stat /mnt/file` shows nanoseconds mtime
3. touch -d '2017-01-01 00:00:00.123456001' /mnt/file

Actual results:
stat shows .123456000, the 001 is gone

Expected results:
stat shows '2017-01-01 00:00:00.123456001'

Additional info:

JoeJulian on IRC pointed at the code:
https://github.com/gluster/glusterfs/blob/c8a23cc6cd289dd28deb136bf2550f28e2761ef3/libglusterfs/src/common-utils.c#L3800-L3841 with the comment:

        /* The granularity is micro seconds as per the current
         * requiremnt. Hence using 'utimes'. This can be updated
         * to 'utimensat' if we need timestamp in nanoseconds.
         */

Please support nano-seconds! It would unbreak lots of backup tools, avoiding unnecessary copying and surprising behaviour.

Comment 1 Shyamsundar 2018-06-20 18:26:20 UTC

This bug reported is against a version of Gluster that is no longer maintained (or has been EOL'd). See https://www.gluster.org/release-schedule/ for the versions currently maintained.

As a result this bug is being closed.

If the bug persists on a maintained version of gluster or against the mainline gluster repository, request that it be reopened and the Version field be marked appropriately.