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:
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)
(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.
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.