Bug 1171048 - Timestamp difference on replica
Summary: Timestamp difference on replica
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: replicate
Version: mainline
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Pranith Kumar K
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1369450 1369451
TreeView+ depends on / blocked
 
Reported: 2014-12-05 09:56 UTC by zsarosi
Modified: 2021-05-10 20:37 UTC (History)
4 users (show)

Fixed In Version: glusterfs-6.x
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1369450 1369451 (view as bug list)
Environment:
Last Closed: 2019-07-02 04:22:59 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description zsarosi 2014-12-05 09:56:37 UTC
Description of problem:
In a replication setup the same file has different timestamps (all three: Access, Modify and Change differ) on the different nodes. The difference is relatively small, in ms range and it is about the same as the difference of the system-clocks. The underlying filesystem is ext4.


Version-Release number of selected component (if applicable):
tested on:
3.6.1
3.5.1
3.4.2


How reproducible:
always

Steps to Reproduce:
0. gluster volume is mounted through glusterfs-fuse on both replica node server using their own hostname to /mnt (on node1: mount -t glusterfs node1:gv_share /mnt; on node2: mount -t glusterfs node2:gv_share /mnt)
1. create file on node1, eg. node1# dd if=/dev/zero of=/mnt/testfile bs=1k count=1
2. node1# stat /mnt/testfile
3. node2# stat /mnt/testfile

Actual results:
The 2 stat results differ with a couple of ms. After "touch"-ing the file, the "modify" timestamp gets updated (rounded to integer s) and then it will be the same on both nodes, however the "change" will be still different.


Expected results:
the 2 stat results should be the same on both nodes

Additional info:
I use ntp to synchronise the system clocks of the nodes but obviously there is always some fluctuation in the ms range.
The differences in the timestams means a problem for IBM TSM backup client: if the TSM client runs on both server and does an incremental backup to a common TSM node. The 2 TSM clients from the two replica servers see different timestamps and wants to update the file on the TSM server however it is the same unchanged file it just has a different timestamp depending on the server on which the TSM client runs.

Comment 1 Anuradha 2016-06-15 09:18:18 UTC
Hi,

We have taken this requirement to be fixed in the upcoming releases.

Thanks,
Anuradha.

Comment 3 Ravishankar N 2018-11-20 05:16:50 UTC
Hello,
The ctime xlator related changes in gluster 5 should solve this issue. Some pointers:
https://docs.gluster.org/en/latest/release-notes/5.0/#standalone
https://github.com/gluster/glusterfs/issues/208
https://github.com/gluster/glusterfs/blob/master/doc/features/ctime.md

Does this solve your use case?

Comment 4 Amar Tumballi 2019-07-02 04:22:59 UTC
ctime feature got introduced to resolve the exact issue, and is available in glusterfs-6.0 onwards, by default in glusterfs volumes.

Comment 5 zsarosi 2021-05-10 20:37:23 UTC
Let's close this bug, I don't have glusterfs anymore.


Note You need to log in before you can comment on or make changes to this bug.