From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Subject: [PATCH 0/2] xfsprogs/db: fix up broken multi-record inode chunk support
Date: Mon, 20 Jun 2016 12:52:40 -0400 [thread overview]
Message-ID: <1466441562-12317-1-git-send-email-bfoster@redhat.com> (raw)
xfs_db/xfs_check doesn't currently handle filesystems with multi-record
inode chunks correctly. For example, do the following on a 64k page size
arch such as ppc64:
# mkfs.xfs -f -b size=64k <dev>
# xfs_db -c check <dev>
bad magic number 0 for inode 1152
bad magic number 0 for inode 1153
bad magic number 0 for inode 1154
bad magic number 0 for inode 1155
bad magic number 0 for inode 1156
bad magic number 0 for inode 1157
...
This boils down to a regression in the inode record processing code
(scanfunc_ino()) in db/check.c. Specifically, the cblocks value can end
up being zero after it is shifted by mp->m_sb.sb_inopblog (i.e., 64 >> 7
== 0 for an -isize=512 -bsize=64k fs).
The xfs_check sparse inode processing code takes a unique approach from
similar code in other areas such as metadump and repair. This was
sufficiently confusing for me that I decided to start with a revert of
the patch that introduced the regression and follow up with a patch that
updates the inode record processing code to take a similar approach as
used in metadump, for example. This approach processes inode chunks a
cluster at a time on sparse inode enabled filesystems and skips the
regions that are sparse according to the record holemask. The two
patches could probably be squashed into one if that is desired, but I'm
posting separately as it describes my workflow.
This survives my testing thus far on sparse inode filesystems as well as
multi-record chunk configurations. These multi-rec configurations don't
exactly have a high test pass rate ;P but I haven't hit any regressions.
BTW, I have noticed that xfs_check seems to also have memory issues with
quotas on multi-inode-rec fs', but that seems to go much farther back
and may just be a limitation of check.
Brian
Brian Foster (2):
Revert "xfs_db: make check work for sparse inodes"
xfs_check: process sparse inode chunks correctly
db/check.c | 274 +++++++++++++++++++++----------------------------------------
1 file changed, 92 insertions(+), 182 deletions(-)
--
2.5.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2016-06-20 16:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 16:52 Brian Foster [this message]
2016-06-20 16:52 ` [PATCH 1/2] Revert "xfs_db: make check work for sparse inodes" Brian Foster
2016-06-20 16:52 ` [PATCH 2/2] xfs_check: process sparse inode chunks correctly Brian Foster
2016-06-21 9:01 ` Carlos Maiolino
2016-06-21 10:48 ` Brian Foster
2016-06-21 12:05 ` Carlos Maiolino
2016-06-21 13:54 ` Eric Sandeen
2016-06-21 23:29 ` Dave Chinner
2016-06-22 8:03 ` Carlos Maiolino
2016-06-22 17:40 ` Darrick J. Wong
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=1466441562-12317-1-git-send-email-bfoster@redhat.com \
--to=bfoster@redhat.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