Hi, I have a question regarding bitrot detection. Following the RedHat manual (https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.3/html/administration_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? Thanks! Omar
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_gluster_storage/3.3/html/administration_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
FNU Raghavendra Manjunath
2018-Apr-18 19:44 UTC
[Gluster-users] Bitrot - Restoring bad file
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>