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@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.
-Eric
HP
--
Harry Percival
Developer
harry@xxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
