Bug 811250 - self heal - dirty afr flags after successfull stat: the empty file two equally dirty servers case
self heal - dirty afr flags after successfull stat: the empty file two equall...
Status: CLOSED WONTFIX
Product: GlusterFS
Classification: Community
Component: replicate (Show other bugs)
3.2.6
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Pranith Kumar K
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-10 10:31 EDT by Rodrigo Severo
Modified: 2014-01-16 04:38 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-16 04:38:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rodrigo Severo 2012-04-10 10:31:06 EDT
Description of problem:
An empty file with dirty flags with the same values on two server stats successfully but remain with dirty AFR flags.

Version-Release number of selected component (if applicable):
All this has been tested with Gluster 3.2.6
I mentioned 3.2.5 at "Version(s)" above for the lack of 3.2.6 option on the dropbox.

How reproducible:
Always

Steps to Reproduce:
1.# getfattr -d -e hex -m . "/brick/empauta_fotografador-2/touch"
getfattr: Removing leading '/' from absolute path names
# file: brick/empauta_fotografador-2/touch
trusted.afr.empauta_fotografador-client-0=0x000000000000000000000000
trusted.afr.empauta_fotografador-client-1=0x000000000000000000000000
trusted.afr.empauta_fotografador-io-threads=0x000000000000000100000000
trusted.afr.empauta_fotografador-replace-brick=0x000000000000000100000000
trusted.gfid=0x31110c34fe7e4b2fa1ab687a3cce679d
2.# getfattr -d -e hex -m . "/brick/empauta_fotografador-1/touch"
getfattr: Removing leading '/' from absolute path names
# file: brick/empauta_fotografador-1/touch
trusted.afr.empauta_fotografador-client-0=0x000000000000000000000000
trusted.afr.empauta_fotografador-client-1=0x000000000000000000000000
trusted.afr.empauta_fotografador-io-threads=0x000000000000000100000000
trusted.afr.empauta_fotografador-replace-brick=0x000000000000000100000000
trusted.gfid=0x31110c34fe7e4b2fa1ab687a3cce679d
3.# stat "/mnt/temp/touch"
  File: `/mnt/temp/touch'
  Size: 0               Blocks: 8          IO Block: 131072 regular empty file
Device: 18h/24d Inode: 18446744073147109399  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-04-10 11:05:37.000000000 -0300
Modify: 2012-04-10 11:05:37.000000000 -0300
Change: 2012-04-10 11:07:12.514528991 -0300
 Birth: -
  
Actual results:
AFR flags remain dirty after successfull stat.

Expected results:
Cleaned AFR flags

Additional info:
This might be a duplicate of bug #811244, please advise.
This might be related to the stat-prefetch issue mentioned by Jeff Darcy at https://bugzilla.redhat.com/show_bug.cgi?id=764232#c14
Comment 1 Amar Tumballi 2012-07-11 01:07:00 EDT
Rodrigo, Can you please try 3.3.0 release and see if its fixed?
Comment 2 Pranith Kumar K 2013-02-22 05:59:24 EST
Rodrigo,
    Could you let us know the steps you took that lead the file into this state.

Pranith.
Comment 3 Rodrigo Severo 2013-02-22 06:08:16 EST
Hi,

I was having major stability problems in my gluster servers caused by bad eletricity and bad UPS so the server were randomly restarted.

When trying to solve split brain scenarios, I found this situation.
Comment 4 Pranith Kumar K 2013-02-22 07:05:16 EST
the dirty flags indicate that they are pending changelog from replace-brick. Any information you could provide about how to re-create such a scenario?.
Comment 5 Rodrigo Severo 2013-02-22 09:23:33 EST
As I said, in reality I got servers getting out of power repeatly in some crazy way. I got all kinds of problems (I filled other bugs for the others similar issues).

To test I would suggest settings the values manually as I can't detail a series of organized steps that would take to this situation.
Comment 6 Pranith Kumar K 2014-01-16 04:38:25 EST
Data migrating part of replace brick is going to be deprecated. Remove-brick and add-brick is taking its place so Closing this bug as won't fix.

Note You need to log in before you can comment on or make changes to this bug.