Bug 1569198

Description of problem:

Currently the existing status command for bitrot scrub shows the list of the corrupted objects (files as of now) for that volume in each of the node

"gluster volume bitrot <volume name> scrub status" gets the GFIDs that are corrupt and on which Host this happens.

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).

The problem is that "getfattr" does not tell what Brick contains the corrupt file. It only gives the path according to the FUSE mount. So it difficult to find which brick the corrupted object belongs to.

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" it is possible to find the correct brick. But the command is possibly expensive.

Version-Release number of selected component (if applicable):


How reproducible:

Always

Steps to Reproduce:
1. Create a gluster volume and start it.
2. Enable bitrot detection on the volume
3. Create some files
4. Simulate bitrot by editing a file directly in the backend brick (instead of the mount point)
5. Run ondemand scrub to start scrubbing
6. Run "gluster volume bitrot <volume name> scrub status" to get the status

Actual results:

The brick where the object (i.e. the gfid) is corrupted is not shown. Only the node is shown.

Expected results:


Additional info: