Bug 1266015 - Not able to recover the corrupted file on Replica volume
Not able to recover the corrupted file on Replica volume
Status: NEW
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: bitrot (Show other bugs)
3.1
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Venky Shankar
Sweta Anandpara
: ZStream
Depends On: 1238171
Blocks: 1216951 1238188 1255604 1255689 1266014
  Show dependency treegraph
 
Reported: 2015-09-24 06:16 EDT by Vivek Agarwal
Modified: 2017-03-25 12:25 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
When an inode is unlinked from the backend (bricks) directly, the corresponding in-memory inode is not cleaned on subsequent lookup. This causes the recovery procedure using healing damons (such as AFR/EC self-heal) to not function as expected as the in-memory inode structure represents a corrupted backend object. Workaround: The object can be deleted directly from the backend and hence the next lookup on the object fails and the inode is forgotten. Now, the self heal daemon heals the object from the good copy.
Story Points: ---
Clone Of: 1238171
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 3 Anjana Suparna Sriram 2015-09-28 02:47:34 EDT
Hi Raghavendra,

Could you please review the edited doc text and sign off for technical accuracy.

Regards,
Anjana
Comment 4 Raghavendra Bhat 2015-09-29 08:16:31 EDT
If the object is deleted directly from the backend, then one does not have to wait till the inode to be forgotten. The next lookup on the object fails and the inode is forgotten right away and lets self heal daemon heal the object from the good copy.
Comment 5 Anjana Suparna Sriram 2015-09-29 08:29:34 EDT
Edited further as per our discussion; please review and sign off.
Comment 6 Raghavendra Bhat 2015-09-29 08:34:56 EDT
Looks good to me.

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