Krutika Dhananjay
2014-Nov-21 03:16 UTC
[Gluster-users] [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.> 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/20141120/13b94646/attachment.html>
Krutika Dhananjay
2014-Nov-22 05:54 UTC
[Gluster-users] [Gluster-devel] In what kind of circumstance, the changlog trusted.afr.xxx of a file will become 0xFFFFFFFF
----- 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>