What would happen if I:
- Did not disable quotas
- Did not stop the volume (140T volume takes at least 3-4 days to do
any find operations, which is too much downtime)
- Find and remove all xattrs:
trusted.glusterfs.quota.242dcfd9-6aea-4cb8-beb2-c0ed91ad70d3.contri on
the /brick/volumename/modules
So after waiting out the process of disabling quotas, waiting for the
xattrs to be cleaned up, re-enabling quotas and waiting for the
xattr's to be created, then applying quotas I'm running into the same
issue.
Yesterday at ~2pm one of the quotas was listed as:
/modules|100.0GB|18.3GB|81.7GB
I
Hi Steve,
Here is how quota usage accounting works
For each file, below extended attributes are set:
trusted.glusterfs.quota..contri -> This value tells how much size this
file/dir has contributed to its parent (key will have a gfid of parent)
For each directory, below extended attributes
Hi Steve,
We suspect the mismatching in accounting is probably because of the
xattr's being not cleaned up properly. Please ensure you do the following
steps and make sure the xattr's are cleaned up properly before quota
is enabled for the next time.
1) stop the volume
2) on each brick in the
Hi Steve,
As you have mentioned, if you are using a glusterfs version lesser than 3.7,
then you are doing it right. We are sorry to say but unfortunately that's the
only
way(manually going and cleaning up the xattr's before enabling quota or wait for
the process to complete itself, which would
