[Top] [All Lists]

Re: trying to avoid a lengthy quotacheck by deleting all quota data

To: xfs@xxxxxxxxxxx
Subject: Re: trying to avoid a lengthy quotacheck by deleting all quota data
From: Harry Percival <harry@xxxxxxxxxxxxxxxxxx>
Date: Fri, 06 Mar 2015 11:27:28 +0000
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <54F8B7D6.2000501@xxxxxxxxxxx>
References: <54EC958E.2000001@xxxxxxxxxxxxxxxxxx> <20150224215907.GA18360@dastard> <54EF1A8F.7030505@xxxxxxxxxxxxxxxxxx> <54F856E7.10006@xxxxxxxxxxxxxxxxxx> <54F87BF3.3000405@xxxxxxxxxxx> <54F88CEC.4030009@xxxxxxxxxxxxxxxxxx> <54F89201.60805@xxxxxxxxxxx> <54F893AF.2070406@xxxxxxxxxxxxxxxxxx> <54F895FA.4050205@xxxxxxxxxxx> <54F89B47.4010702@xxxxxxxxxxxxxxxxxx> <54F8B7D6.2000501@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
Glad we managed to nail down a probable culprit! Here's hoping Debian and Ubuntu pull in a new kernel :)

In other news, any advice on running this


command as a way of estimating how long a quotacheck will take? Would it still be a useful estimator? Do you think it would significantly affect the performance of a disk that's under fairly heavy use?


On 05/03/15 20:08, Eric Sandeen wrote:
On 3/5/15 12:07 PM, Harry wrote:
Here's the syslog, if you're curious.


Search for "Failed to initialize"
Ok, there is no other message offering more info, sadly.

So your best guess is that it's the drbd layer that's causing the
quotacheck?  Out of curiosity, i may try mounting a non-drbd drive
with xfs, and seeing if we can still repro the
hard-reboot-causes-quotacheck thing...  Unless you think it's just an
old behaviour that's more to do with the version of the kernel we're
I really don't have a good guess at this point..... oh, wait, finally,
a bell goes off:

commit 5ef828c4152726f56751c78ea844f08d2b2a4fa3
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date:   Mon Aug 4 11:35:44 2014 +1000

     xfs: avoid false quotacheck after unclean shutdown
The commit 83e782e xfs: Remove incore use of XFS_OQUOTA_ENFD and XFS_OQUOTA_CHKD added a new function xfs_sb_quota_from_disk() which swaps
     on-disk XFS_OQUOTA_* flags for in-core XFS_GQUOTA_* and XFS_PQUOTA_*
     flags after the superblock is read.
However, if log recovery is required, the superblock is read again,
     and the modified in-core flags are re-read from disk, so we have
     XFS_OQUOTA_* flags in memory again.  This causes the
     XFS_QM_NEED_QUOTACHECK() test to be true, because the XFS_OQUOTA_CHKD
     is still set, and not XFS_GQUOTA_CHKD or XFS_PQUOTA_CHKD.
Change xfs_sb_from_disk to call xfs_sb_quota_from disk and always
     convert the disk flags to in-memory flags.
Add a lower-level function which can be called with "false" to
     not convert the flags, so that the sb verifier can verify
     exactly what was on disk, per Brian Foster's suggestion.
Reported-by: Cyril B. <cbay@xxxxxxxxxxxxx>
     Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>

83e782e went in at v3.11; the above commit hit v3.17, so it was broken
for a while.

I still can't explain the "quota init failed" bit, but the above
probably explains the unexpected quotacheck problem.



Harry Percival

PythonAnywhere - a fully browser-based Python development and hosting 

PythonAnywhere LLP
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79
Registered in England and Wales as company number OC378414.
Registered address: 28 Ely Place, 3rd Floor, London EC1N 6TD, UK

<Prev in Thread] Current Thread [Next in Thread>