Bug 1266015

Summary: Not able to recover the corrupted file on Replica volume
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Vivek Agarwal <vagarwal>
Component: bitrotAssignee: Venky Shankar <vshankar>
Status: CLOSED DUPLICATE QA Contact: Sweta Anandpara <sanandpa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rhgs-3.1CC: annair, asriram, atumball, mzywusko, rabhat, rhs-bugs, sankarshan, smohan, vshankar
Target Milestone: ---Keywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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: 2018-03-13 09:59:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1238171    
Bug Blocks: 1216951, 1238188, 1255604, 1255689, 1266014    

Comment 3 Anjana Suparna Sriram 2015-09-28 06:47:34 UTC
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 12:16:31 UTC
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 12:29:34 UTC
Edited further as per our discussion; please review and sign off.

Comment 6 Raghavendra Bhat 2015-09-29 12:34:56 UTC
Looks good to me.

Comment 9 Amar Tumballi 2018-03-13 09:59:15 UTC

*** This bug has been marked as a duplicate of bug 1238171 ***