From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Cc: gux.fnst@cn.fujitsu.com
Subject: [PATCH] xfsprogs/repair: only check secondary sb->sb_pquotino for v5 superblocks
Date: Mon, 30 Mar 2015 10:53:26 -0400 [thread overview]
Message-ID: <1427727206-14280-1-git-send-email-bfoster@redhat.com> (raw)
xfs_repair scans for garbage data beyond the last valid superblock field
for the particular sb version in secondary_sb_wack(). If any non-zero
data is detected, the entire range is reset to zero. Subsequently,
various valid superblock fields are checked for valid/expected data.
The sb_pquotino field is checked unconditionally as part of this
sequence even though it is a v5 only field. As a result, repair
complains about a non-null project quota field if any garbage data
exists for a v4 secondary sb. This is reproduced by xfs/070 against a v4
superblock and is also easily reproduced manually as follows:
$ mkfs.xfs -f -m crc=0 <dev>
$ xfs_db -x -c "sb 3" -c "write lsn 1" <dev>
$ xfs_repair <dev>
...
zeroing unused portion of secondary superblock (AG #3)
non-null project quota inode field in superblock 3
...
This occurs because the garbage data detection mechanism has reset
sb->sb_pquotino to 0 while the validity check expects a value of
NULLFSINO.
Update secondary_sb_wack() to only check sb->sb_pquotino for validity on
supers where it is a valid field. If it is anything other than 0 on
pre-v5 superblocks, it is explicitly reset to 0 by the garbage data
checks earlier in the function.
Reported-by: Xing Gu <gux.fnst@cn.fujitsu.com>
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
| 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--git a/repair/agheader.c b/repair/agheader.c
index 416dbd8..5dbf992 100644
--- a/repair/agheader.c
+++ b/repair/agheader.c
@@ -377,7 +377,13 @@ secondary_sb_wack(
rval |= XR_AG_SB_SEC;
}
- if (sb->sb_inprogress == 1 && sb->sb_pquotino != NULLFSINO) {
+ /*
+ * Note that sb_pquotino is not considered a valid sb field for pre-v5
+ * superblocks. If it is anything other than 0 it is considered garbage
+ * data beyond the valid sb and explicitly zeroed above.
+ */
+ if (xfs_sb_version_has_pquotino(&mp->m_sb) &&
+ sb->sb_inprogress == 1 && sb->sb_pquotino != NULLFSINO) {
if (!no_modify) {
sb->sb_pquotino = 0;
dsb->sb_pquotino = 0;
--
1.9.3
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
reply other threads:[~2015-03-30 14:53 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1427727206-14280-1-git-send-email-bfoster@redhat.com \
--to=bfoster@redhat.com \
--cc=gux.fnst@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox