+++ 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.
REVIEW: https://review.gluster.org/16667 (posix: use nanosecond accuracy when available) posted (#1) for review on master by Anonymous Coward
REVIEW: https://review.gluster.org/16667 (posix: use nanosecond accuracy when available) posted (#2) for review on master by Anonymous Coward
REVIEW: https://review.gluster.org/16667 (posix: use nanosecond accuracy when available) posted (#3) for review on master by Niklas Hambüchen
REVIEW: https://review.gluster.org/16789 (tests: Fix and enable split-brain-healing mtime check) posted (#1) for review on master by Niklas Hambüchen
REVIEW: https://review.gluster.org/16789 (tests: Fix and enable split-brain-healing mtime check) posted (#2) for review on master by Niklas Hambüchen
REVIEW: https://review.gluster.org/16667 (posix: use nanosecond accuracy when available) posted (#4) for review on master by Niklas Hambüchen
REVIEW: https://review.gluster.org/16789 (tests: Fix and enable split-brain-healing mtime check) posted (#3) for review on master by Niklas Hambüchen
COMMIT: https://review.gluster.org/16789 committed in master by Jeff Darcy (jdarcy) ------ commit c78d07fb8efdd5f63284332473852619d5da4244 Author: Niklas Hambüchen <mail> Date: Tue Feb 28 14:05:59 2017 +0100 tests: Fix and enable split-brain-healing mtime check This test was commented out with the belief that it depended on utimensat() support, but in fact it was not necessary because `stat -c %Y` only outputs second resolution. Simply commenting in the test made it fail because it checked the values *before* the heal, while intended was to check them *after* the heal. This commit fixes that. Change-Id: I4194ac645b365a1f906a3ac9bcbbdb1f05000e27 BUG: 1422074 Signed-off-by: Niklas Hambüchen <mail> Reviewed-on: https://review.gluster.org/16789 Reviewed-by: Ravishankar N <ravishankar> Tested-by: Ravishankar N <ravishankar> Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Niklas Hambüchen
REVIEW: https://review.gluster.org/16667 (posix: use nanosecond accuracy when available) posted (#5) for review on master by Niklas Hambüchen
REVIEW: https://review.gluster.org/16667 (posix: use nanosecond accuracy when available) posted (#6) for review on master by Niklas Hambüchen
COMMIT: https://review.gluster.org/16667 committed in master by Jeff Darcy (jdarcy) ------ commit ce8d8195dc253a87cceaaeeb1a725090471ae4f8 Author: Niklas Hambüchen <mail> Date: Sat Feb 18 00:49:02 2017 +0100 posix: use nanosecond accuracy when available 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. BUG: 1422074 Change-Id: I89c7b6a73e2e06c02851ff76b7e5cdfaa271e985 Signed-off-by: Niklas Hambüchen <mail> Reviewed-on: https://review.gluster.org/16667 Smoke: Gluster Build System <jenkins.org> Reviewed-by: Niels de Vos <ndevos> Tested-by: Jeff Darcy <jdarcy> NetBSD-regression: NetBSD Build System <jenkins.org> Reviewed-by: jiffin tony Thottan <jthottan> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Jeff Darcy <jdarcy>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.11.0, please open a new bug report. glusterfs-3.11.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://lists.gluster.org/pipermail/announce/2017-May/000073.html [2] https://www.gluster.org/pipermail/gluster-users/