<div>Hi,</div><div><br></div>This means that the geo-replication indexing ("xtime" extended attributes) has gone inconsistent. If these xattrs wasn't tampered with by an outside actor (ie. anything that is not the gsyncd process spawned upon the "geo-replication start", and its children), then this happens if the clock of the master box (more precisely, any brick which belongs to the master volume) is set backwards. In that case the whole indexing is gone corrupt and to fix it, you should reset the index with<div>
<br></div><div># gluster volume set <master volume> geo-replication.indexing off</div><div># gluster volume set <master volume> geo-replication.indexing on</div><div><br></div><div>(for this you should first stop geo-rep sessions with <master volume> as master; they can be restarted after the index reset). The side effect of this operation is that a full rsync-style synchronization will be performed once, ie. files will be checked if match by means of a two-side checksum.<br>
<div><br></div><div>Regards,</div><div>Csaba</div><div><br><div class="gmail_quote">On Mon, Jun 27, 2011 at 11:57 PM, Anand Babu Periasamy <span dir="ltr"><<a href="mailto:ab@gluster.com">ab@gluster.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Tue, Jun 21, 2011 at 2:37 PM, Adrian Carpenter <span dir="ltr"><<a href="mailto:tac12@wbic.cam.ac.uk" target="_blank">tac12@wbic.cam.ac.uk</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm evaluating geo-replication feature of 3.2.1, and today two of the volumes that I am replicating have both stopped with the same error )although different files, here are some logs:<br>
<br>
File "/opt/glusterfs/3.2.1/local/libexec/glusterfs/python/syncdaemon/master.py", line 215, in crawl<br>
raise RuntimeError("timestamp corruption for " + path)<br>
RuntimeError: timestamp corruption for ./x86_64/freesurfer4/freesurfer-4.0.5/mni/include/bicpl<br>
<br>
I have deleted the file and copied it back from another source, which appears to fix the problem, although of course in a test environment this is OK, in production it would be an issue.<br>
<br>
Are there other suggestions to correct this problem?<br>
<br>
Adrian<br>
<br>
p.s. the volume is replicated.<br><br></blockquote><div><br></div><div>Adrian, </div><div>Thanks for reporting this bug. We will look in to this issue. This exception should be trapped and healed appropriately. Will file a bug and keep you in the loop.</div>
</div><div> </div><div>Csaba, can you please followup.</div><div><br></div><font color="#888888"><div>-- <br>Anand Babu Periasamy<br>Blog [<a href="http://www.unlocksmith.org/" target="_blank">http://www.unlocksmith.org</a>]<br>
<br>Imagination is more important than knowledge --Albert Einstein<br>
</div>
</font></blockquote></div><br></div></div>