public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Harry Percival <harry@pythonanywhere.com>
To: xfs@oss.sgi.com
Subject: Re: trying to avoid a lengthy quotacheck by deleting all quota data
Date: Fri, 06 Mar 2015 11:27:28 +0000	[thread overview]
Message-ID: <54F98F20.9000208@pythonanywhere.com> (raw)
In-Reply-To: <54F8B7D6.2000501@sandeen.net>

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

     xfstests:src/bstat

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?

hp

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.
>>
>> http://pastebin.com/raw.php?i=kKvWJcze
>>
>> 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
>> using?
> I really don't have a good guess at this point..... oh, wait, finally,
> a bell goes off:
>
> commit 5ef828c4152726f56751c78ea844f08d2b2a4fa3
> Author: Eric Sandeen <sandeen@sandeen.net>
> 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@excellency.fr>
>      Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>
>
> 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.
>
> -Eric
>
>> HP

-- 
Harry Percival
Developer
harry@pythonanywhere.com

PythonAnywhere - a fully browser-based Python development and hosting environment
<http://www.pythonanywhere.com/>

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2015-03-06 11:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-24 15:15 trying to avoid a lengthy quotacheck by deleting all quota data Harry
2015-02-24 16:39 ` Harry
2015-02-24 17:33 ` Ben Myers
2015-02-24 17:59   ` Harry Percival
2015-02-24 18:12     ` Ben Myers
2015-02-24 21:59 ` Dave Chinner
2015-02-26 13:07   ` Harry
2015-03-05 13:15     ` Harry
2015-03-05 15:53       ` Eric Sandeen
2015-03-05 17:05         ` Harry
2015-03-05 17:09           ` Harry
2015-03-05 17:27           ` Eric Sandeen
2015-03-05 17:34             ` Harry
2015-03-05 17:44               ` Eric Sandeen
2015-03-05 18:07                 ` Harry
2015-03-05 20:08                   ` Eric Sandeen
2015-03-06 11:27                     ` Harry Percival [this message]
2015-03-06 21:11                       ` Dave Chinner
2015-03-25 12:34                         ` Harry Percival
2015-03-07 13:41                   ` Arkadiusz Miśkiewicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54F98F20.9000208@pythonanywhere.com \
    --to=harry@pythonanywhere.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox