Bug 1457272

Summary:	Old content on last node when using Cascade Geo Replication in a particular case
Product:	[Community] GlusterFS	Reporter:	guillaume.penin
Component:	geo-replication	Assignee:	bugs <bugs>
Status:	CLOSED EOL	QA Contact:
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	3.10	CC:	bugs
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-06-20 18:27:01 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description guillaume.penin 2017-05-31 12:39:30 UTC

Description of problem:

Using a 3 nodes Cascade Geo Replication Setup (node1 => node2 => node3), file content is never updated on node3 after modification on node1 in this particular case :

- Use a shell redirection to modify file content
- File size is the same as before

File attributes (modification time for example) are however OK.

Version-Release number of selected component (if applicable):

GlusterFS 3.10.2 on Ubuntu 16.04 LTS x86_64

How reproducible:

Always

Steps to Reproduce:
1. Create a file on node1 (/bin/date "+%s" > /export/repos/.monitoring_timestamp), it will be correctly replicated on node2 and node3
2. Modify file content with the same command on node1, it will be correctly replicated on node2 but not on node3.

Actual results:

Node 1 :
Content => 1496233967
ls => 11893925174562343327 -rw-r--r-- 1 root root 11 May 31 14:32 /export/repos/.monitoring_timestamp
Node 2 :
Content => 1496233967
ls = 11893925174562343327 -rw-r--r-- 1 root root 11 May 31 14:32 /export/repos/.monitoring_timestamp
Node 3 :
Content => 1496233801
ls => 11893925174562343327 -rw-r--r-- 1 root root 11 May 31 14:32 /export/repos/.monitoring_timestamp

Expected results:

Node 1 :
Content => 1496233967
ls => 11893925174562343327 -rw-r--r-- 1 root root 11 May 31 14:32 /export/repos/.monitoring_timestamp
Node 2 :
Content => 1496233967
ls = 11893925174562343327 -rw-r--r-- 1 root root 11 May 31 14:32 /export/repos/.monitoring_timestamp
Node 3 :
Content => 1496233967
ls => 11893925174562343327 -rw-r--r-- 1 root root 11 May 31 14:32 /export/repos/.monitoring_timestamp

Comment 1 guillaume.penin 2017-08-21 11:59:11 UTC

Hi,

Just confirming that this issue persists in GlusterFS 3.10.5. Any clue ? Am I missing something in my configuration ?

Thanks.

Comment 2 Shyamsundar 2018-06-20 18:27:01 UTC

This bug reported is against a version of Gluster that is no longer maintained (or has been EOL'd). See https://www.gluster.org/release-schedule/ for the versions currently maintained.

As a result this bug is being closed.

If the bug persists on a maintained version of gluster or against the mainline gluster repository, request that it be reopened and the Version field be marked appropriately.

Comment 3 Shyamsundar 2018-06-20 18:27:41 UTC

This bug reported is against a version of Gluster that is no longer maintained
(or has been EOL'd). See https://www.gluster.org/release-schedule/ for the
versions currently maintained.

As a result this bug is being closed.

If the bug persists on a maintained version of gluster or against the mainline
gluster repository, request that it be reopened and the Version field be marked
appropriately.