All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Harry <harry@pythonanywhere.com>, xfs@oss.sgi.com
Subject: Re: trying to avoid a lengthy quotacheck by deleting all quota data
Date: Thu, 05 Mar 2015 14:08:54 -0600	[thread overview]
Message-ID: <54F8B7D6.2000501@sandeen.net> (raw)
In-Reply-To: <54F89B47.4010702@pythonanywhere.com>

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

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

  reply	other threads:[~2015-03-05 20:09 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 [this message]
2015-03-06 11:27                     ` Harry Percival
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=54F8B7D6.2000501@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=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.