[Gluster-users] Bitrot - Restoring bad file

FNU Raghavendra Manjunath rabhat at redhat.com
Wed Apr 18 19:44:47 UTC 2018


Hi,

Patch [1] has been sent for review. The path also prints the brick to which
the corrupted object (file) belongs to.

With the patch the output of the scrub status command looks like this.

"
# gluster volume bitrot repl scrub status

Volume name : repl

State of scrub: Active (Idle)

Scrub impact: lazy

Scrub frequency: biweekly

Bitrot error log location: /var/log/glusterfs/bitd.log

Scrubber error log location: /var/log/glusterfs/scrub.log


=========================================================

Node: localhost

Number of Scrubbed files: 0

Number of Skipped files: 0

Last completed scrub time: Scrubber pending to complete.

Duration of last scrub (D:M:H:M:S): 0:0:0:0

Error count: 2

Corrupted object's [GFID]:

0f9818b8-b762-4e5b-b3c9-bdd53b5fb1cb ==> BRICK: /export1/repl

7ce298fb-290f-4c2b-abaf-1dd0fca9bbb1 ==> BRICK: /export2/repl

=========================================================
"

Still some effort is needed to find the file to which the gfid (shown in
the corrupted objects field of scrub status command) belongs to.
But in situations where there are multiple bricks running on the same node
for a particular volume, then checking in all the bricks is not
needed.

Please check whether it is something which makes things better compared to
now.

[1] https://review.gluster.org/#/c/19901/1

On Tue, Apr 17, 2018 at 11:59 PM, Aravinda <avishwan at redhat.com> wrote:

> On 04/17/2018 06:25 PM, Omar Kohl wrote:
>
>> Hi,
>>
>> I have a question regarding bitrot detection.
>>
>> Following the RedHat manual (https://access.redhat.com/doc
>> umentation/en-us/red_hat_gluster_storage/3.3/html/administra
>> tion_guide/bitrot-restore_corrupt_file) I am trying out
>> bad-file-restoration after bitrot.
>>
>> "gluster volume bitrot VOLNAME status" gets me the GFIDs that are corrupt
>> and on which Host this happens.
>>
>> As far as I can tell the preferred way of finding out what file maps to
>> that GFID is using "getfattr" (assuming all Gluster and mount options were
>> set as described in the link).
>>
>> My problem is that "getfattr" does not tell me what Brick contains the
>> corrupt file. It only gives me the path according to the FUSE mount. So how
>> do I find out what brick the file is on?
>>
>> If we assume that every brick is on a distinct host then we have no
>> problem because "bitrot status" gave us the hostname. So we can infer what
>> brick is meant. But in general you can't assume there are not several
>> bricks per host, right?
>>
>> With "find" (as described in the link above) it is possible to find the
>> correct brick. But the command is possibly expensive and I get the feeling
>> that "getfattr" is the recommended way.
>>
>> Any thoughts?
>>
>
> Another getfattr can give brick details where that file is residing
>
>     getfattr -n glusterfs.pathinfo <path of file>
>
> where path can be <mount>/.gfid/<gfid> or absolute path of file.
>
>
>> Thanks!
>> Omar
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-users
>>
>
>
> --
> regards
> Aravinda VK
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20180418/ba19854e/attachment.html>


More information about the Gluster-users mailing list