<div dir="ltr">We&#39;re currently running Gluster 3.6.5 on CentOS 6.  We are planning on upgrading to 3.7.x sometime soon if that will resolve our issues, but this being a high traffic production environment it&#39;s hard to schedule downtime to do so.<div><br></div><div>We have also tried creating a new, empty slave volume, and setting up a new geo-replication link.  Even with that all of the data on the master isn&#39;t copied.  It get&#39;s about half-way, goes into &quot;Changelog Crawl&quot; mode, and then only syncs new data.  Because of that we&#39;ve stopped using geo-replication for now, and set up some rsync scripts instead.</div><div><br></div><div>If there&#39;s a 100% effective and officially supported way of forcing a full sync that would be great.  None of the suggestions/tips/workarounds I&#39;ve seen on the lists so far have worked to do so.<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><br><div>Thank You,</div><div><br></div><div>Logan Barfield</div><div>Tranquil Hosting</div></div></div></div>
<br><div class="gmail_quote">On Fri, Oct 23, 2015 at 1:26 AM, Aravinda <span dir="ltr">&lt;<a href="mailto:avishwan@redhat.com" target="_blank">avishwan@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    Hi,<br>
    <br>
    First error &quot;Operation not permitted&quot; looks like due to GFID
    conflict. We are working on auto resolving GFID conflict issues so
    that Geo-replication will not halt due to these issues. Please let
    us know which version of Gluster you are using so that we can
    provide workaround steps to re-sync the Skipped files.<br>
    <br>
    Log file records Skipped files GFIDs, we can retrigger the sync for
    those GFIDs if required. Sometimes these errors(rsync/tar) are due
    to errors in some files but Geo-replication records as SKIPPED for
    the entire batch. We are working on recording failures more
    granular. <br>
    <pre cols="72">regards
Aravinda</pre><div><div class="h5">
    <div>On 10/14/2015 08:36 PM, Logan Barfield
      wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      <pre>We had a connectivity issue on a &quot;tar+ssh&quot; geo-rep link yesterday that
caused a lot of issues.  When the link came back up it immediately went
into a &quot;faulty&quot; state, and the logs were showing &quot;Operation not permitted&quot;
and &quot;File Exists&quot; errors in a loop.

We were finally able to get things back on track by shutting down the
geo-rep link, killing the hung tar processes on the slave, and bringing the
link back up in &quot;rsync&quot; mode.

The master is now back in a &quot;Changelog Crawl&quot; status, and I have confirmed
new files are being copied to the slave correctly.

The status on the master is currently showing 100k+ &quot;FILED SKIPPED.&quot;

My question is: Where can I see which files were skipped, and how can I
force them to replicate/update to the slave?

</pre>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>_______________________________________________
Gluster-users mailing list
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a>
<a href="http://www.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-users</a></pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>