From: Eric Sandeen <sandeen@sandeen.net>
To: Roger Willcocks <roger@filmlight.ltd.uk>,
Leslie Rhorer <lrhorer@mygrande.net>
Cc: Brian Foster <bfoster@redhat.com>,
Kris Rusocki <kszysiu@braxis.org>,
"Rhorer, Leslie" <Leslie.Rhorer@level3.com>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: XFS File system in trouble
Date: Sat, 15 Aug 2015 13:48:18 -0500 [thread overview]
Message-ID: <55CF8972.8020306@sandeen.net> (raw)
In-Reply-To: <74DC7EBF-0029-4E5E-9D96-DF193E2BE83F@filmlight.ltd.uk>
On 8/15/15 7:28 AM, Roger Willcocks wrote:
> xfs_repair 3.2.1 runs cleanly.
>
> xfs_repair 3.1.1 complains about a load of stuff, including:
I wouldn't expect v3.1.1 to work at all, because:
# db/xfs_db -V
xfs_db version 4.2.0-rc1
# db/xfs_db /mnt/test2/leslie/md0.img -c version
versionnum [0xbdb4+0x8a] = V4,NLINK,DIRV2,ATTR,ALIGN,DALIGN,LOGV2,EXTFLG,SECTOR,MOREBITS,ATTR2,LAZYSBCOUNT,PROJID32BIT
the filesystem has 32-bit project IDs, and:
# git log --oneline | grep -i "projid32bit"
dd536e1 xfsprogs: Note projid32bit default change in mkfs.xfs manpage
22bc10e xfsprogs: projid32bit handling
# git describe --contains 22bc10e
v3.1.4~2
that feature support didn't show up until v3.1.4. Were you running a stock v3.1.1?
Anyway, in my testing, up to v3.2.0, repair finds a lot of errors (and spends some
time looking for a proper superblock)
v3.2.1 finds no errors.
The errors stopped showing up as of:
commit d085fb486f8b33304f2fdf704411313ffc8bcc0c
Author: Dave Chinner <dchinner@redhat.com>
Date: Tue Jul 8 10:36:39 2014 +1000
repair: fix quota inode handling in secondary superblocks
Changes to support separate project quota inodes changed the way
quota inodes got written to the superblock. The current code is
tailored for the needs to the kernel, where the inodes should only
be written if certain falgs are set saying a quota type is enabled.
Unfortunately, when recovering a corrupt secondary superblock, we
need to unconditionally write the quota inode fields after we
unconditionally zero the quota flags field. The result of this bug
is that the bad quota inode fields cannot be cleared and hence
always are reported by bad by repair in subsequent runs.
Fix this by directly clearing the quota inodes in the superblock
buffers so that we do need to set special flags to get
xfs_sb_to_disk() to do the right thing as setting flags leave bad
flag values in the superblock instead of bad inode numbers....
Also, when clearing the inode numbers, write them as NULLFSINO
rather than 0 as this is what the kernel will write them as if quota
is turned off.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
I'll have to look into that commit, and the errors found prior.
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-08-15 18:48 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-18 1:46 XFS File system in trouble Rhorer, Leslie
2015-07-18 14:16 ` Eric Sandeen
2015-07-18 17:23 ` Rhorer, Leslie
2015-07-18 17:47 ` Kris Rusocki
2015-07-18 18:12 ` Leslie Rhorer
2015-07-19 1:02 ` Leslie Rhorer
2015-07-19 23:27 ` Dave Chinner
2015-07-20 7:41 ` Leslie Rhorer
2015-07-20 8:05 ` Martin Papik
2015-07-20 8:35 ` Leslie Rhorer
2015-07-20 8:52 ` Martin Papik
2015-07-20 13:08 ` Gim Leong Chin
2015-07-20 13:34 ` Eric Sandeen
2015-07-23 3:18 ` Eric Sandeen
2015-07-24 13:47 ` Leslie Rhorer
2015-07-24 14:44 ` Eric Sandeen
2015-07-24 15:29 ` Rhorer, Leslie
2015-07-20 11:17 ` Brian Foster
2015-07-23 1:45 ` Leslie Rhorer
2015-07-23 11:36 ` Brian Foster
2015-07-28 7:46 ` Leslie Rhorer
2015-07-28 8:35 ` Stefan Ring
2015-07-28 10:48 ` Roger Willcocks
2015-07-28 12:33 ` Brian Foster
2015-07-28 15:13 ` Leslie Rhorer
2015-07-28 16:53 ` Eric Sandeen
2015-07-28 19:12 ` Martin Papik
2015-07-28 19:52 ` Martin Steigerwald
2015-07-28 22:11 ` Brian Foster
2015-08-02 20:24 ` Leslie Rhorer
2015-08-04 7:52 ` Leslie Rhorer
2015-08-04 12:19 ` Brian Foster
2015-08-04 22:42 ` Dave Chinner
2015-08-10 1:37 ` Leslie Rhorer
2015-08-13 6:21 ` Leslie Rhorer
2015-08-14 1:26 ` Dave Chinner
2015-08-14 23:12 ` Leslie Rhorer
2015-08-15 12:28 ` Roger Willcocks
2015-08-15 18:48 ` Eric Sandeen [this message]
2015-08-15 18:57 ` Roger Willcocks
2015-08-15 22:48 ` Dave Chinner
2015-08-15 19:00 ` Eric Sandeen
2015-08-15 19:13 ` Roger Willcocks
2015-08-16 0:32 ` Eric Sandeen
2015-08-18 2:14 ` Dave Chinner
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=55CF8972.8020306@sandeen.net \
--to=sandeen@sandeen.net \
--cc=Leslie.Rhorer@level3.com \
--cc=bfoster@redhat.com \
--cc=kszysiu@braxis.org \
--cc=lrhorer@mygrande.net \
--cc=roger@filmlight.ltd.uk \
--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