There are couple of things here: 1. With 3.5, geo-replication would also take care to maintain the GFIDs of files to be in sync. Syncing data using rsync this way would haves mangled the GFIDs. This is very much similar to an upgrade scenario to 3.5 where data synced by geo-rep pre 3.5 would not have the GFIDs in sync. So, you would need to follow the upgrade steps here[1].
2. Regarding geo-rep replicating already replicated data, as of now there is no *easy *way to _tell_ gsyncd to skip hybrid crawl and start processing live changes (a.k.a. *changelog* mode). Maybe we could generate the metadata but not replicate anything, but then, if we're fully sure data is in sync after a session restart. [1]: https://github.com/gluster/glusterfs/blob/release-3.5/doc/upgrade/geo-rep-upgrade-steps.md Thanks, -venky On Tue, May 27, 2014 at 6:37 PM, James Le Cuirot <ch...@aura-online.co.uk>wrote: > Hello, > > I've set up geo-rep under 3.5 over a slow link. There are 75GB of data > and I already have it present on the slave. The data has been fully > synced with rsync beforehand but gluster still seems to insist on fully > resyncing everything. I left it overnight and it's still chewing up all > our bandwidth in hybrid crawl mode. Is there any way to tell it that > the slave is already up to date? I know it probably has to generate > some metadata but does that really mean all the data has to be resent? > > Regards, > James > _______________________________________________ > Gluster-users mailing list > Gluster-users@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users >
_______________________________________________ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
