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.
On Tue, Apr 17, 2018 at 11:59 PM, Aravinda <avishwan@xxxxxxxxxx> 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/documentation/en-us/red_hat_glust ) I am trying out bad-file-restoration after bitrot.er_storage/3.3/html/administra tion_guide/bitrot-restore_ corrupt_file
"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@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-users
--
regards
Aravinda VK
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-users
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-users
