All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.