[Gluster-users] Gluster 3.10.5: used disk size reported by quota and du mismatch

[Mauro Tridici]

Hi Sanoj,

unfortunately the output of the command execution was not helpful.

[root at s01 ~]# find /tier2/CSP/ans004  | xargs getfattr -d -m. -e hex
[root at s01 ~]# 

Do you have some other idea in order to detect the cause of the issue?

Thank you again,
Mauro


> Il giorno 05 lug 2018, alle ore 09:08, Sanoj Unnikrishnan <sunnikri at redhat.com> ha scritto:
> 
> Hi Mauro,
> 
> A script issue did not capture all necessary xattr. 
> Could you provide the xattrs with.. 
> find /tier2/CSP/ans004  | xargs getfattr -d -m. -e hex
> 
> Meanwhile, If you are being impacted, you could do the following
> back up quota limits 
> disable quota
> enable quota
> freshly set the limits.
> 
> Please capture the xattr values first, so that we can get to know what went wrong.
> Regards,
> Sanoj
> 
> 
> On Tue, Jul 3, 2018 at 4:09 PM, Mauro Tridici <mauro.tridici at cmcc.it <mailto:mauro.tridici at cmcc.it>> wrote:
> Dear Sanoj,
> 
> thank you very much for your support.
> I just downloaded and executed the script you suggested.
> 
> This is the full command I executed:
> 
> ./quota_fsck_new.py --full-logs --sub-dir /tier2/CSP/ans004/ /gluster
> 
> In attachment, you can find the logs generated by the script.
> What can I do now?
> 
> Thank you very much for your patience.
> Mauro
> 
> 
> 
> 
>> Il giorno 03 lug 2018, alle ore 11:34, Sanoj Unnikrishnan <sunnikri at redhat.com <mailto:sunnikri at redhat.com>> ha scritto:
>> 
>> Hi Mauro, 
>> 
>> This may be an issue with update of backend xattrs. 
>> To RCA further and provide resolution could you provide me with the logs by running the following fsck script.
>> https://review.gluster.org/#/c/19179/6/extras/quota/quota_fsck.py <https://review.gluster.org/#/c/19179/6/extras/quota/quota_fsck.py>
>> 
>> Try running the script and revert with the logs generated.
>> 
>> Thanks,
>> Sanoj
>> 
>> 
>> On Mon, Jul 2, 2018 at 2:21 PM, Mauro Tridici <mauro.tridici at cmcc.it <mailto:mauro.tridici at cmcc.it>> wrote:
>> Dear Users,
>> 
>> I just noticed that, after some data deletions executed inside "/tier2/CSP/ans004” folder, the amount of used disk reported by quota command doesn’t reflect the value indicated by du command.
>> Surfing on the web, it seems that it is a bug of previous versions of Gluster FS and it was already fixed.
>> In my case, the problem seems unfortunately still here.
>> 
>> How can I solve this issue? Is it possible to do it without starting a downtime period?
>> 
>> Thank you very much in advance,
>> Mauro
>> 
>> [root at s01 ~]# glusterfs -V
>> glusterfs 3.10.5
>> Repository revision: git://git.gluster.org/glusterfs.git <>
>> Copyright (c) 2006-2016 Red Hat, Inc. <https://www.gluster.org/ <https://www.gluster.org/>>
>> GlusterFS comes with ABSOLUTELY NO WARRANTY.
>> It is licensed to you under your choice of the GNU Lesser
>> General Public License, version 3 or any later version (LGPLv3
>> or later), or the GNU General Public License, version 2 (GPLv2),
>> in all cases as published by the Free Software Foundation.
>> 
>> [root at s01 ~]# gluster volume quota tier2 list /CSP/ans004
>>                   Path                   Hard-limit  Soft-limit      Used  Available  Soft-limit exceeded? Hard-limit exceeded?
>> -------------------------------------------------------------------------------------------------------------------------------
>> /CSP/ans004                                1.0TB     99%(1013.8GB)    3.9TB  0Bytes             Yes                  Yes
>> 
>> [root at s01 ~]# du -hs /tier2/CSP/ans004/
>> 295G	/tier2/CSP/ans004/
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
>> http://lists.gluster.org/mailman/listinfo/gluster-users <http://lists.gluster.org/mailman/listinfo/gluster-users>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20180705/665734e2/attachment.html>