Bug 1251614

Summary: gf_defrag_fix_layout recursively fails, distracting from the root cause
Product: [Community] GlusterFS Reporter: Joe Julian <joe>
Component: distributeAssignee: Barak Sason Rofman <bsasonro>
Status: CLOSED UPSTREAM QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: mainlineCC: bugs, spalai, srangana
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: dht-failed-rebalance
Fixed In Version: glusterfs-6.x Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-12 14:49:36 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:

Description Joe Julian 2015-08-07 22:04:17 UTC
In df_defrag_fix_layout if a recursive call to itself fails, all parent directories also fail (lines 2550-2560). I don't believe that the fix_layout actually fails on those parent directories as the extended attribute was applied  successfully in line 2539.

Comment 1 Amar Tumballi 2019-05-07 21:14:12 UTC
With introduction of commit-hash and other things in rebalance, this looks more fool proof, and didn't see any issues in latest codebase. Will mark it as WORKSFORME (with glusterfs-6.x) release. If the issue persists, will take it up in one of the future releases.

Comment 2 Nithya Balachandran 2019-05-08 03:28:18 UTC
Reopening this as this still exists.

Comment 4 Susant Kumar Palai 2020-02-18 08:23:07 UTC
I guess we can fix the issue by changing the state to STOP after encountering a fix-layout failure so that the callers won't report a failure.

Comment 5 Worker Ant 2020-03-10 09:25:50 UTC
REVIEW: https://review.gluster.org/24210 (dht/rebalance - fixing recursive failure issue) posted (#1) for review on master by Barak Sason Rofman

Comment 6 Worker Ant 2020-03-12 14:49:36 UTC
This bug is moved to https://github.com/gluster/glusterfs/issues/1072, and will be tracked there from now on. Visit GitHub issues URL for further details