[Gluster-devel] heal info output

[Xavi Hernandez]

Hi Emmanuel,

On Thu, Jul 2, 2020 at 3:05 AM Emmanuel Dreyfus <manu at netbsd.org> wrote:

> Hello
>
> gluster volume heal info show me questionable entries. I wonder if these
> are bugs, or if I shoud handle them and how.
>
> bidon# gluster volume heal gfs info
> Brick bidon:/export/wd0e_tmp
> Status: Connected
> Number of entries: 0
>
> Brick baril:/export/wd0e
> /.attribute/system
> <gfid:7f3a4aa5-7a49-4f50-a166-b345cdf0616c>
> Status: Connected
> Number of entries: 2
>
> (...)
> Brick bidon:/export/wd2e
> <gfid:d616f804-0579-4649-8d8e-51ec4cf0e131>
> <gfid:f4eb6db3-8341-454b-9700-81ad4ebca61e>
> /owncloud/data
> <gfid:43b80fd9-a577-4568-b400-2d80bb4d25ad>
> <gfid:7253faad-6843-4321-a63f-17671237d607>
> <gfid:da055475-43c0-4157-b4f1-30b3647bc0b6>
> <gfid:02f4f38e-f351-4bb8-bd43-cad64ba5a4f5>
>
> There are three cases:
> 1) /.attribute directory is special on NetBSD, it is where extended
> attributes are stored for the filesystem. The posix xlator takes care of
> screening it, but there must be some other softrware component that
> should learn it must disregeard it. Hints are welcome about where I
> should look at.
>

Is the '.attribute' directory only present on the root directory of a
filesystem ? if so I strongly recommend to never use the root of a
filesystem to place bricks. Always place the brick into a subdirectory.


> 2) /owncloud/data  is a directory. mode, owner and groups are the same
> on bricks. Why is it listed here?
>

If files or subdirectories have been created or removed from that directory
and the operation failed on some brick (or the brick was down), the
directory is also marked as bad. You should also check the contents.


> 3) <gfid:...> What should I do with this?
>

These are files or directories for whose real path is not known. If
gfid2path feature is enabled, you can check the
trusted.gfid2path.xxxxxx xattr on the gfid. It shows the gfid of the parent
directory and the file name. The full path can be retrieved by following
the directory symlinks or using the gfid-to-dirname.sh script in the extras
directory.

If gfid2path is not enabled, I fear that finding them will need to be done
by bruteforce:

1. Get the inode number of one of the gfid entries on one brick.
2. Run 'find <brick root> -inum <inode number>

Once you find the entries, if you do an 'stat' on the mount point of the
volume, the next "gluster volume heal info" should show the real path of
the files instead its gfid

Regards,

Xavi

-- 
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu at netbsd.org
> _______________________________________________
>
> Community Meeting Calendar:
>
> Schedule -
> Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
> Bridge: https://bluejeans.com/441850968
>
>
>
>
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20200706/aba4468f/attachment.html>