[Gluster-devel] self heal fails

Robert Hassing rhassing at service2media.com
Mon Jun 11 10:07:39 UTC 2012


Hi

Did someone find the cause of this problem?
I got into the same situation.

Setup:

Brink1
Brick2
Several clients

After shutting doen one of the bricks, we write some data to the shared filesystem
After bringing the brick back online self heal fails with the error below.
>From what I can tell, self heal only fails on symlinks (that didn't change) in the folder where the changes have been made.

Regards
Robert Hassing


From:

Pranith Kumar Karampuri

Subject:

Re: [Gluster-devel] self heal fails

Date:

Tue, 05 Jun 2012 10:19:15 -0400 (EDT)

________________________________
Emmanuel,
     For some reason /manu/netbsd/usr/src/lib/libkafs/libkafs.so.9 and its
parent dir have trusted.gfid all zero, this is worse. This is brand new for me.
Do let me know if you have a test case to get into this situation.

Pranith
----- Original Message -----
From: "Emmanuel Dreyfus" <address at hidden>
To: "Pranith Kumar Karampuri" <address at hidden>
Cc: "Emmanuel Dreyfus" <address at hidden>, address at hidden
Sent: Tuesday, June 5, 2012 7:01:24 PM
Subject: Re: [Gluster-devel] self heal fails

On Tue, Jun 05, 2012 at 07:57:16AM -0400, Pranith Kumar Karampuri wrote:
>     If lookup triggers self-heal and the self-heal fails, lookup
> wont fail unless it is a splitbrain on the entry i.e. gfid mismatch.
> There seems to be a problem in the logs you have mentioned. For
> some reason the gfid is all zeros, I wonder how you hit this case.
> Do you have a testcase that can re-create this case.

It keeps going on for now, but I do not know how I got this situation.

> Could you post the output of
> 'getfattr -d -m . -e hex' for /manu/netbsd/usr/src/lib/libkafs,
> /manu/netbsd/usr/src/lib/libkafs/libkafs.so.9,
> /manu/netbsd/usr/src/lib/libkafs/libkafs.so On both the bricks.

The commands are a bit different, but here is the info:
brick0
  manu/netbsd/usr/src/lib/libkafs/
    trusted.afr.pfs-client-1
      00 00 00 00 00 00 00 00 00 00 00 03 00
    trusted.afr.pfs-client-0
      00 00 00 00 00 00 00 00 00 00 00 00 00
    trusted.gfid
      00 00 00 00 00 00 00 00 00 00 00 00 00
  manu/netbsd/usr/src/lib/libkafs/libkafs.so.9
    trusted.afr.pfs-client-1
      00 00 00 00 00 00 00 00 00 00 00 00 00
    trusted.afr.pfs-client-0
      00 00 00 00 00 00 00 00 00 00 00 00 00
    trusted.gfid
      00 00 00 00 00 00 00 00 00 00 00 00 00
  manu/netbsd/usr/src/lib/libkafs/libkafs.so
    trusted.afr.pfs-client-1
      be 77 68 6e ba d2 45 d2 8c c2 1a 0e 37 9a 44 0a
    trusted.afr.pfs-client-0
      a4 19 75 e7 f9 be 44 09 bb e8 70 76 6a 04 95 46
    trusted.gfid
      a4 19 75 e7 f9 be 44 09 bb e8 70 76 6a 04 95 46

brick1
  manu/netbsd/usr/src/lib/libkafs/
    trusted.afr.pfs-client-1
      ENODATA
    trusted.afr.pfs-client-0
      ENODATA
   trusted.gfid
      be 77 68 6e ba d2 45 d2 8c c2 1a 0e 37 9a 44 0a
  manu/netbsd/usr/src/lib/libkafs/libkafs.so.9
    trusted.afr.pfs-client-1
      00 00 00 00 00 00 00 00 00 00 00 00 00
    trusted.afr.pfs-client-0
      00 00 00 00 00 00 00 00 00 00 00 00 00
    trusted.gfid
      a4 19 75 e7 f9 be 44 09 bb e8 70 76 6a 04 95 46
  manu/netbsd/usr/src/lib/libkafs/libkafs.so
    trusted.afr.pfs-client-1
      00 00 00 00 00 00 00 00 00 00 00 00 00
    trusted.afr.pfs-client-0
      00 00 00 00 00 00 00 00 00 00 00 00 00
    trusted.gfid
      a4 19 75 e7 f9 be 44 09 bb e8 70 76 6a 04 95 46

I am a bit suprised that libkafs.so and libkafs.so.9.0 have the
same gfid: They are just symlinks to the same node. Bug?
Here is ls -lid on brick1:

17407737 drwxr-xr-x  3 manu  manu  1024 Jun  5 13:31
        manu/netbsd/usr/src/lib/libkafs/
17434245 lrwxrwxrwx  2 manu  manu    14 Jun  4 07:38
        manu/netbsd/usr/src/lib/libkafs/libkafs.so -> libkafs.so.9.0
17433620 lrwxrwxrwx  2 manu  manu    14 Jun  4 07:38
        manu/netbsd/usr/src/lib/libkafs/libkafs.so.9 -> libkafs.so.9.0

I wonder if my recent chang with linkat could have introduced a bug.

--
Emmanuel Dreyfus
address at hidden



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120611/38deb82c/attachment-0003.html>


More information about the Gluster-devel mailing list