diff options
author | Kotresh H R <khiremat@redhat.com> | 2014-08-01 16:12:38 +0530 |
---|---|---|
committer | Vijay Bellur <vbellur@redhat.com> | 2014-08-04 07:51:07 -0700 |
commit | 0e8c537d6f48857b0f3c0ef10ce1c4458e303be8 (patch) | |
tree | 5a41d0e21b186d2c8d8589a5542930fcbb2fb0fe /tests/utils/arequal-checksum.c | |
parent | 51394183e94ac0be70fcf22793b2040ba3f0b918 (diff) |
feature/geo-rep: Keep marker.tstamp's mtime unchangeable during snapshot.
Problem:
Geo-replicatoin does a full xsync crawl after snapshot
restoration of slave and master. It does not do history crawl.
Analysis:
Marker creates 'marker.tstamp' file when geo-rep is started
for the first time. The virtual extended attribute
'trusted.glusterfs.volume-mark' is maintained and whenever
it is queried on gluster mount point, marker fills it on
the fly and returns the combination of uuid, ctime of
marker.tstamp and others. So ctime of marker.tstamp, in other
sense 'volume-mark' marks the geo-rep start time when the
session is freshly created.
From the above, after the first filesystem crawl(xsync) is
done during first geo-rep start, stime should always be less
than 'volume-mark'. So whenever stime is less than volume-mark,
it does full filesystem crawl (xsync).
Root Cause:
When snapshot is restored, marker.tstamp file is freshly
created losing the timestamps, it was originally created with.
Solution:
1. Change is made to depend on mtime instead of ctime.
2. mtime and atime of marker.tstamp is restored back when
snapshot is created and restored.
Change-Id: I4891b112f4aedc50cfae402832c50c5145807d7a
BUG: 1125918
Signed-off-by: Kotresh H R <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/8401
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Diffstat (limited to 'tests/utils/arequal-checksum.c')
0 files changed, 0 insertions, 0 deletions