Bug 1225546

Summary:	Pass slave volume in geo-rep as read-only
Product:	[Community] GlusterFS	Reporter:	Cyril Peponnet <cyril>
Component:	geo-replication	Assignee:	bugs <bugs>
Status:	CLOSED EOL	QA Contact:
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	3.5.2	CC:	avishwan, bugs, pladd, vshankar, zsarosi
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	Feature: Slave volume RO when geo-rep is active Reason: Avoid to corrupt gfid on slave Result: set read-only option to vol	Story Points:	---
Clone Of:
Clones:	1288113 1288114 1288115 (view as bug list)		Environment:
Last Closed:	2016-06-17 15:58:07 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:
Bug Depends On:
Bug Blocks:	1288113, 1288114, 1288115, 1430608, 1531932

Description Cyril Peponnet 2015-05-27 16:17:35 UTC

Description of problem:

By default the slave volume can be mounted as RW and people can change file. This will lead to gfid mismatch and geo-rep fails for those files.

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

Any

How reproducible:

Always

Steps to Reproduce:
1. create a geo-repo
2. change file in slave
3. change file in master, they are no longer propagated

Actual results:

Several:

In case of modification, they are not propagated to the slave
In case of deletion, the file is kept on slave
In case of rename, the file on slave is also renamed with content from slave file.

Expected results:

No able to touch files from a slave vol when a geo-rep process is running / created for that vol.

Additional info:

Comment 1 Patrick Ladd 2015-12-02 20:18:14 UTC

I have a customer that had end users mount the slave and make modifications to it.  Any write activity to the slave, as noted in the comments above, causes long term problems for geo-replication that may not be recoverable without a complete rebuild of the slave.

After some discussion with gluster engineers, it appears that gluster geo-rep itself mounts the slave volume to operate on it.  Therefore, implementation for this would have to have some way to restrict non-geo rep mounts to read only while still allowing the geo-rep process to mount rw and operate on the slave.  Maybe a "super secret" mount option that geo-rep uses to distinguish itself?  (Clearly being an open source project it won't really be secret but at least someone would have to consciously use it and accept the consequences)

Comment 2 Aravinda VK 2015-12-03 02:26:58 UTC

(In reply to Patrick Ladd from comment #1)
> I have a customer that had end users mount the slave and make modifications
> to it.  Any write activity to the slave, as noted in the comments above,
> causes long term problems for geo-replication that may not be recoverable
> without a complete rebuild of the slave.
> 
> After some discussion with gluster engineers, it appears that gluster
> geo-rep itself mounts the slave volume to operate on it.  Therefore,
> implementation for this would have to have some way to restrict non-geo rep
> mounts to read only while still allowing the geo-rep process to mount rw and
> operate on the slave.  Maybe a "super secret" mount option that geo-rep uses
> to distinguish itself?  (Clearly being an open source project it won't
> really be secret but at least someone would have to consciously use it and
> accept the consequences)

Geo-replication mounts volumes using "-o aux-gfid-mount" option. In Gluster code this can be identified as CLIENT_PID = -1 or CLIENT_PID = GSYNCD.

If you mount a Volume as read-only, it will not affect Geo-replication.

Comment 4 Niels de Vos 2016-06-17 15:58:07 UTC

This bug is getting closed because the 3.5 is marked End-Of-Life. There will be no further updates to this version. Please open a new bug against a version that still receives bugfixes if you are still facing this issue in a more current release.