Bug 969384

Summary:	[FEAT] Reduce the number of crawls the self-heal daemon needs to make
Product:	[Community] GlusterFS	Reporter:	Niels de Vos <ndevos>
Component:	replicate	Assignee:	Krutika Dhananjay <kdhananj>
Status:	CLOSED EOL	QA Contact:
Severity:	low	Docs Contact:
Priority:	medium
Version:	mainline	CC:	bugs, gluster-bugs, kdhananj
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-22 15:46:38 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:
Bug Blocks:	917686

Description Niels de Vos 2013-05-31 10:34:13 UTC

It seems that the self-heal daemon needs N+1 crawls of the volume (where N is
the maximum depth of the directory structure). At the moment, the indexes that
are used by the self-heal daemon do not have any ordering information. If
there would be some ordering, it would be possible to heal directories first,
and files afterwards. The number of crawls could be reduced that way and the
errors related to healing files in directories that do not exist yet would be
prevented (see Bug 969353).

Comment 1 Pranith Kumar K 2014-04-22 04:43:14 UTC

We found one way to do this where the number of crawls could be reduced to 2 irrespective of the depth of directory structure. I recently discovered that posix has the ability to give full directory hierarchy given any directory gfid because .glusterfs of the brick stores a softlink for <pargfid>/dirname for every directory. So in the first crawl for every directory self-heal-daemon needs to heal the entire directory hierarchy (i.e create/delete the files). Then only files will remain to be healed which will be healed in the second crawl i.e. metadata/data heals.

Pranith

Comment 2 Kaleb KEITHLEY 2015-10-22 15:46:38 UTC

because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.