+++ 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.