[Bugs] [Bug 1486063] New: 0 kByte file not self-healing with replica 2 + arbiter

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1486063

            Bug ID: 1486063
           Summary: 0 kByte file not self-healing with replica 2 + arbiter
           Product: GlusterFS
           Version: 3.8
         Component: selfheal
          Severity: medium
          Assignee: bugs at gluster.org
          Reporter: mabi at protonmail.ch
                CC: bugs at gluster.org



Created attachment 1319232
  --> https://bugzilla.redhat.com/attachment.cgi?id=1319232&action=edit
self-heal daemon log file of all 3 nodes

Description of problem:
I have a 3 nodes replica-2+arbiter where one single 0 kBytes big file is stuck
in self-heal and as such never gets healed. The whole issue has been
extensively discussed and described on the gluster-users mailing list here: 

http://lists.gluster.org/pipermail/gluster-users/2017-August/032105.html

For easiness I have pasted a few relevant infos here below, starting with the
heal info output:

Brick node1.domain.tld:/data/myvolume/brick
/data/appdata_ocpom4nckwru/preview/1344699/64-64-crop.png
Status: Connected
Number of entries: 1

Brick node2.domain.tld:/data/myvolume/brick
/data/appdata_ocpom4nckwru/preview/1344699/64-64-crop.png
Status: Connected
Number of entries: 1

Brick node3.domain.tld:/srv/glusterfs/myvolume/brick
/data/appdata_ocpom4nckwru/preview/1344699/64-64-crop.png
Status: Connected
Number of entries: 1

A stat and getfattr of the file on each brick:

NODE1:

STAT:
  File:
‘/data/myvolume/brick/data/appdata_ocpom4nckwru/preview/1344699/64-64-crop.png’
  Size: 0         Blocks: 38         IO Block: 131072 regular empty file
Device: 24h/36d Inode: 10033884    Links: 2
Access: (0644/-rw-r--r--)  Uid: (   33/www-data)   Gid: (   33/www-data)
Access: 2017-08-14 17:04:55.530681000 +0200
Modify: 2017-08-14 17:11:46.407404779 +0200
Change: 2017-08-14 17:11:46.407404779 +0200
Birth: -

GETFATTR:
trusted.afr.dirty=0sAAAAAQAAAAAAAAAA
trusted.bit-rot.version=0sAgAAAAAAAABZhuknAAlJAg==
trusted.gfid=0sGYXiM9XuTj6lGs8LX58q6g==
trusted.glusterfs.d99af2fa-439b-4a21-bf3a-38f3849f87ec.xtime=0sWZG9sgAGOyo=

NODE2:

STAT:
  File:
‘/data/myvolume/brick/data/appdata_ocpom4nckwru/preview/1344699/64-64-crop.png’
  Size: 0         Blocks: 38         IO Block: 131072 regular empty file
Device: 26h/38d Inode: 10031330    Links: 2
Access: (0644/-rw-r--r--)  Uid: (   33/www-data)   Gid: (   33/www-data)
Access: 2017-08-14 17:04:55.530681000 +0200
Modify: 2017-08-14 17:11:46.403704181 +0200
Change: 2017-08-14 17:11:46.403704181 +0200
Birth: -

GETFATTR:
trusted.afr.dirty=0sAAAAAQAAAAAAAAAA
trusted.bit-rot.version=0sAgAAAAAAAABZhu6wAA8Hpw==
trusted.gfid=0sGYXiM9XuTj6lGs8LX58q6g==
trusted.glusterfs.d99af2fa-439b-4a21-bf3a-38f3849f87ec.xtime=0sWZG9sgAGOVE=

NODE3:
STAT:
  File:
/srv/glusterfs/myvolume/brick/data/appdata_ocpom4nckwru/preview/1344699/64-64-crop.png
  Size: 0         Blocks: 0          IO Block: 4096   regular empty file
Device: ca11h/51729d Inode: 405208959   Links: 2
Access: (0644/-rw-r--r--)  Uid: (   33/www-data)   Gid: (   33/www-data)
Access: 2017-08-14 17:04:55.530681000 +0200
Modify: 2017-08-14 17:04:55.530681000 +0200
Change: 2017-08-14 17:11:46.604380051 +0200
Birth: -

GETFATTR:
trusted.afr.dirty=0sAAAAAQAAAAAAAAAA
trusted.bit-rot.version=0sAgAAAAAAAABZe6ejAAKPAg==
trusted.gfid=0sGYXiM9XuTj6lGs8LX58q6g==
trusted.glusterfs.d99af2fa-439b-4a21-bf3a-38f3849f87ec.xtime=0sWZG9sgAGOc4=

CLIENT GLUSTER MOUNT:
STAT:
  File:
'/mnt/myvolume/data/appdata_ocpom4nckwru/preview/1344699/64-64-crop.png'
  Size: 0         Blocks: 0          IO Block: 131072 regular empty file
Device: 1eh/30d Inode: 11897049013408443114  Links: 1
Access: (0644/-rw-r--r--)  Uid: (   33/www-data)   Gid: (   33/www-data)
Access: 2017-08-14 17:04:55.530681000 +0200
Modify: 2017-08-14 17:11:46.407404779 +0200
Change: 2017-08-14 17:11:46.407404779 +0200
Birth: -

Version-Release number of selected component (if applicable):
GlusterFS 3.8.11 on Debian 8

How reproducible:
AFAIK Ravishankar managed to reproduced the problem.

Steps to Reproduce:
1. Ask Ravi
2.
3.

Actual results:


Expected results:


Additional info:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.