[Gluster-users] [Gluster-devel] In what kind of circumstance, the changlog trusted.afr.xxx of a file will become 0xFFFFFFFF

[Krutika Dhananjay]

----- Original Message -----

> From: "Krutika Dhananjay" <kdhananj at redhat.com>
> To: "Jaden Liang" <jaden1q84 at gmail.com>
> Cc: gluster-users at gluster.org
> Sent: Friday, November 21, 2014 8:46:42 AM
> Subject: Re: [Gluster-devel] In what kind of circumstance, the changlog
> trusted.afr.xxx of a file will become 0xFFFFFFFF

> Changing cc'd group to gluster-users.

> Hi,

> Could you provide the client and brick logs (bricks 8 and 9 when counting
> from 0)?

> -Krutika

> ----- Original Message -----

> > From: "Jaden Liang" <jaden1q84 at gmail.com>
> 
> > To: gluster-devel at gluster.org
> 
> > Sent: Friday, November 21, 2014 8:16:42 AM
> 
> > Subject: [Gluster-devel] In what kind of circumstance, the changlog
> > trusted.afr.xxx of a file will become 0xFFFFFFFF
> 

> > Hi all,
> 

> > I have a glusterfs-3.4.5 build with 6 x 2 Distributed-Replicate volume for
> > KVM storage. And found one of the file is not in a consistant state. I
> > checked the extent attributes of every replica file on brick as below:
> 

> > # file:
> > sf/data/vs/local/d2c2bf42-0206-43db-824b-d2d3872ea42d/98d0e5d0-44c6-4284-ae09-aa0a232056c7/images/cluster/b6da49e44cec/test.vm/vm-disk-1.qcow2
> 
> > trusted.afr.vs_vol_rep2-client-8=0xffffffff0000000000000000
> 
> > trusted.afr.vs_vol_rep2-client-9=0x000000000000000000000000
> 
> > trusted.gfid=0xca90124fa56d42bba7a2840719ed74d6
> 
> > trusted.glusterfs.lockinfo=0x0000000100000075000000093c504f534958282f73662f646174612f76732f6c6f63616c2f34313831616363352d633532332d343033662d383664352d3033346566656337316434652f39386430653564302d343463362d343238342d616530392d616130613233323035366337293a686f73742d34633732623965366461376500313733313236313600
> 

> > # file:
> > sf/data/vs/local/4181acc5-c523-403f-86d5-034efec71d4e/98d0e5d0-44c6-4284-ae09-aa0a232056c7/images/cluster/b6da49e44cec/test.vm/vm-disk-1.qcow2
> 
> > trusted.afr.vs_vol_rep2-client-8=0x000000000000000000000000
> 
> > trusted.afr.vs_vol_rep2-client-9=0x000000000000000000000000
> 
> > trusted.gfid=0xca90124fa56d42bba7a2840719ed74d6
> 
> > trusted.glusterfs.lockinfo=0x0000000100000075000000093c504f534958282f73662f646174612f76732f6c6f63616c2f34313831616363352d633532332d343033662d383664352d3033346566656337316434652f39386430653564302d343463362d343238342d616530392d616130613233323035366337293a686f73742d34633732623965366461376500313733313236313600
> 

> > There is a trusted.afr.vs_vol_rep2-client-8=0xffffffff0000000000000000.
> > BTW,
> > one of t he servers did disconnect for less than 1 minute then came back 1
> > miute and keep this loop for one 12 hours(Just testing the glusterfs
> > behavior in bad network circumstance). As I know, the changelog of
> > aft-xlator is modified by increase or decrease with 1. I think i t is
> > unlikely the operations increase to 0xFFFFFFFF. It might be some buggy code
> > decrease changelog to -1 which is 0xFFFFFFFF.
> 

And yes, to answer your question, this does seem like a bug, where a post-op of -1 on the changelog whose value was 0 before could have led to a value of 0xffffffff. 
-Krutika 

> > Just sending this mail here, may be there is someone met this before or
> > knowing what is going on.
> 

> > Thanks.
> 

> > _______________________________________________
> 
> > Gluster-devel mailing list
> 
> > Gluster-devel at gluster.org
> 
> > http://supercolony.gluster.org/mailman/listinfo/gluster-devel
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20141122/3a89789d/attachment.html>