Bug 1289047 - Not able to recover a file in a replicated volume when bit rot is enabled
Not able to recover a file in a replicated volume when bit rot is enabled
Status: NEW
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: bitrot (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Venky Shankar
: ZStream
Depends On:
  Show dependency treegraph
Reported: 2015-12-07 05:20 EST by RamaKasturi
Modified: 2017-03-25 12:26 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description RamaKasturi 2015-12-07 05:20:23 EST
Description of problem:
When a file is marked as corrupted by bitrot recovering the file from the replicated volume, does not work.

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

How reproducible:

Steps to Reproduce:
1. Create tiered volume with both hot and cold bricks as dist-rep and enable bitrot on the volume.
2. Fuse mount the volume and create some data into it.
3. Now edit one of the file from backend so that scrubber will mark the file as bad file in one of the subvolume.
3. Do I/O from the mount point so that all the I/O will go the other file.
4. Now try to recover the file by deleting the file and its gfid from backend and launching self heal command.

Actual results:
only meta data heal completes and data heal does not. Heal info always shows that there are some entries to heal.

Expected results:
Heal should complete sucessfully and file should be recovered.

Additional info:
Comment 2 RamaKasturi 2015-12-07 05:56:46 EST
sos reports can be found in the link http://rhsqe-repo.lab.eng.blr.redhat.com/sosreports/1289047/

Note You need to log in before you can comment on or make changes to this bug.