Bug 1123067

Summary:	User is not informed, nor is there a way to check if completed, the quota xattr cleanup after disabling quota
Product:	[Community] GlusterFS	Reporter:	Joe Julian <joe>
Component:	quota	Assignee:	Manikandan <mselvaga>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.5.2	CC:	bugs, mselvaga, smohan, vmallika
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	All
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-20 08:30:45 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 2014-07-24 18:40:27 UTC

http://review.gluster.org/6369/ introduced an automatic cleanup of quota xattrs. If the user disables quota and immediately re-enables quota, inconsistent things seem to happen, including differences between df and du and brick crashes.

I suspect this is due to the cleanup script having not yet completed. Since the user was unaware of the script's existence, he did not anticipate any problems.

At the very least, a notice should be displayed from the CLI when quota is disabled telling the user what to look for to determine if the cleanup has finished.

Comment 1 Vijaikumar Mallikarjuna 2015-01-22 08:29:26 UTC

One solution we can think of is to maintain version for quota-xattrs, with this we can enable/disable quota, while the cleanup script is still running.

Comment 2 Vijaikumar Mallikarjuna 2015-12-21 09:12:06 UTC

Hi Joe,

This issue has been fixed in 3.7 with versioning the xattrs.

Comment 3 Vijaikumar Mallikarjuna 2016-04-20 08:30:45 UTC

As per comment# 2, problem of quota accounting inconsistency with disabling and enabling quota is solved with quota-xattr versioning feature introduced in 3.7.
Also there is no plan for back-porting this feature to 3.5, so closing this bug