Back to bug 1361518

Who When What Removed Added
Red Hat Bugzilla Rules Engine 2016-07-29 09:21:07 UTC Keywords ZStream
Pranith Kumar K 2016-08-02 08:16:22 UTC Blocks 1351522
Rahul Hinduja 2016-08-07 14:27:15 UTC CC rhinduja
Rejy M Cyriac 2016-08-09 11:38:22 UTC Keywords ZStream
CC rcyriac
Red Hat Bugzilla Rules Engine 2016-08-09 11:38:28 UTC Target Release --- RHGS 3.2.0
Atin Mukherjee 2016-08-30 05:34:04 UTC Status NEW POST
CC amukherj
Karan Sandha 2016-09-30 09:16:52 UTC Severity medium high
Karan Sandha 2016-09-30 09:20:49 UTC Priority unspecified high
Nag Pavan Chilakam 2016-09-30 12:11:08 UTC CC nchilaka
QA Contact storage-qa-internal ksandha
Pranith Kumar K 2016-11-20 17:19:35 UTC Flags needinfo?(ravishankar)
Ravishankar N 2016-11-23 02:53:26 UTC Flags needinfo?(ravishankar)
Ravishankar N 2016-11-23 04:09:23 UTC Doc Text Problem:
If a file create is wound to all bricks, and the FOP succeeds only on arbiter, the application will get a failure, but during self-heal conservative merge, the zero byte file gets created on the data bricks with arbiter marked as source. Since data self-heal can never happen from arbiter, 'heal-info' will list the entries forever.

Workaround:
If 'gluster vol heal <volname> info` shows pending data heals for a file which is zero byte size on all bricks, it should be safe to delete the file from the mount, subsequent to which the file should also no longer appear in heal-info output.
Doc Type If docs needed, set a value Known Issue
Ravishankar N 2016-11-24 10:35:08 UTC Doc Text Problem:
If a file create is wound to all bricks, and the FOP succeeds only on arbiter, the application will get a failure, but during self-heal conservative merge, the zero byte file gets created on the data bricks with arbiter marked as source. Since data self-heal can never happen from arbiter, 'heal-info' will list the entries forever.

Workaround:
If 'gluster vol heal <volname> info` shows pending data heals for a file which is zero byte size on all bricks, it should be safe to delete the file from the mount, subsequent to which the file should also no longer appear in heal-info output.
Problem:
If a file create is wound to all bricks, and it succeeds only on arbiter, the application will get a failure, but during self-heal, the file gets created on the data bricks with arbiter marked as source. Since data self-heal can never happen from arbiter, 'heal-info' will list the entries forever.

Workaround:
If 'gluster vol heal <volname> info` shows pending heals for a file forever, see identify that it is the above probem by:

i) checking that trusted.afr.volname-client* xattrs are zero on the data bricks

ii)checking that trusted.afr.volname-client* xattrs is non-zero on the arbiter brick *only* for the data part (first 4 bytes)
Example:
#getfattr -d -m . -e hex /bricks/arbiterbrick/file |grep trusted.afr.testvol*
getfattr: Removing leading '/' from absolute path names
trusted.afr.testvol-client-0=0x000000540000000000000000
trusted.afr.testvol-client-1=0x000000540000000000000000

If it is in this state, then delete the xattr:

#for i in $(getfattr -d -m . -e hex /bricks/arbiterbrick/file |grep trusted.afr.testvol*|cut -f1 -d'='); do setfattr -x $i file; done
Ravishankar N 2016-11-24 10:35:55 UTC Blocks 1351530
Atin Mukherjee 2016-11-24 12:40:00 UTC Blocks 1351522
Ravishankar N 2017-02-16 05:54:43 UTC Blocks 1417147
Atin Mukherjee 2017-02-20 11:41:56 UTC Target Release RHGS 3.2.0 ---
Red Hat Bugzilla Rules Engine 2017-02-28 10:15:17 UTC Target Release --- RHGS 3.3.0
Atin Mukherjee 2017-03-10 11:17:51 UTC Status POST ASSIGNED
Bhavana 2017-03-15 03:31:37 UTC CC bmohanra
Doc Text Problem:
If a file create is wound to all bricks, and it succeeds only on arbiter, the application will get a failure, but during self-heal, the file gets created on the data bricks with arbiter marked as source. Since data self-heal can never happen from arbiter, 'heal-info' will list the entries forever.

Workaround:
If 'gluster vol heal <volname> info` shows pending heals for a file forever, see identify that it is the above probem by:

i) checking that trusted.afr.volname-client* xattrs are zero on the data bricks

ii)checking that trusted.afr.volname-client* xattrs is non-zero on the arbiter brick *only* for the data part (first 4 bytes)
Example:
#getfattr -d -m . -e hex /bricks/arbiterbrick/file |grep trusted.afr.testvol*
getfattr: Removing leading '/' from absolute path names
trusted.afr.testvol-client-0=0x000000540000000000000000
trusted.afr.testvol-client-1=0x000000540000000000000000

If it is in this state, then delete the xattr:

#for i in $(getfattr -d -m . -e hex /bricks/arbiterbrick/file |grep trusted.afr.testvol*|cut -f1 -d'='); do setfattr -x $i file; done
If a file create is wound to all bricks, and it succeeds only on arbiter, the application will get a failure. But during self-heal, the file gets created on the data bricks with arbiter marked as source. Since data self-heal can never happen from arbiter, 'heal-info' will list the entries forever.

Workaround:
If 'gluster vol heal <volname> info` shows the pending heals for a file forever, then check if the issue is the same as mentioned above by:

i) checking that trusted.afr.volname-client* xattrs are zero on the data bricks

ii)checking that trusted.afr.volname-client* xattrs is non-zero on the arbiter brick *only* for the data part (first 4 bytes)
Example:
#getfattr -d -m . -e hex /bricks/arbiterbrick/file |grep trusted.afr.testvol*
getfattr: Removing leading '/' from absolute path names
trusted.afr.testvol-client-0=0x000000540000000000000000
trusted.afr.testvol-client-1=0x000000540000000000000000

If it is in this state, then delete the xattr:

#for i in $(getfattr -d -m . -e hex /bricks/arbiterbrick/file |grep trusted.afr.testvol*|cut -f1 -d'='); do setfattr -x $i file; done
Atin Mukherjee 2017-05-17 12:29:26 UTC Target Release RHGS 3.3.0 ---
Blocks 1417147
Red Hat Bugzilla Rules Engine 2017-06-28 09:09:30 UTC Keywords ZStream
Amar Tumballi 2018-04-16 18:16:27 UTC Status ASSIGNED CLOSED
Resolution --- WONTFIX
Last Closed 2018-04-16 14:16:27 UTC
Bipin Kunal 2018-11-06 10:10:22 UTC CC bkunal
Bipin Kunal 2018-11-06 10:11:13 UTC CC atumball
Flags needinfo?(atumball)
Amar Tumballi 2018-11-06 10:15:02 UTC Resolution WONTFIX UPSTREAM
Flags needinfo?(atumball)
Bipin Kunal 2018-11-08 12:11:44 UTC Flags needinfo?(atumball)
Ravishankar N 2018-11-08 12:16:02 UTC Flags needinfo?(atumball)

Back to bug 1361518