Geo-rep failing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

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

# gluster volume set <master volume> geo-replication.indexing off
# gluster volume set <master volume> geo-replication.indexing on

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

Regards,
Csaba

On Mon, Jun 27, 2011 at 11:57 PM, Anand Babu Periasamy <ab at gluster.com>wrote:

> On Tue, Jun 21, 2011 at 2:37 PM, Adrian Carpenter <tac12 at wbic.cam.ac.uk>wrote:
>
>> 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:
>>
>> File
>> "/opt/glusterfs/3.2.1/local/libexec/glusterfs/python/syncdaemon/master.py",
>> line 215, in crawl
>>    raise RuntimeError("timestamp corruption for " + path)
>> RuntimeError: timestamp corruption for
>> ./x86_64/freesurfer4/freesurfer-4.0.5/mni/include/bicpl
>>
>> 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.
>>
>> Are there other suggestions to correct this problem?
>>
>> Adrian
>>
>> p.s. the volume is replicated.
>>
>>
> Adrian,
> 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.
>
> Csaba, can you please followup.
>
> --
> Anand Babu Periasamy
> Blog [http://www.unlocksmith.org]
>
> Imagination is more important than knowledge --Albert Einstein
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gluster.org/pipermail/gluster-users/attachments/20110628/fc9c5aab/attachment.htm>


[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux