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:
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon Aug 4 11:35:44 2014 +1000
xfs: avoid false quotacheck after unclean shutdown
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.