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):
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
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.
the 2 stat results should be the same on both nodes
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.
We have taken this requirement to be fixed in the upcoming releases.
The ctime xlator related changes in gluster 5 should solve this issue. Some pointers:
Does this solve your use case?
ctime feature got introduced to resolve the exact issue, and is available in glusterfs-6.0 onwards, by default in glusterfs volumes.
Let's close this bug, I don't have glusterfs anymore.