From: Eric Sandeen <sandeen@sandeen.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 01/14] repair: merge scanfunc_bno and scanfunc_cnt
Date: Mon, 12 Oct 2009 11:53:00 -0500 [thread overview]
Message-ID: <4AD35EEC.4080707@sandeen.net> (raw)
In-Reply-To: <20090902175839.915684396@bombadil.infradead.org>
Christoph Hellwig wrote:
> Those two functions are almost identical. The big difference is that
> we only
> move blocks from XR_E_FREE1 to XR_E_FREE state when processing the cnt btree.
>
> Besides that we print bno vs cnt in the messages and obviously validate a
> slightly different magic number in the header.
>
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>
Generally seems fine to me, a couple of nitpicks below, take 'em or leave 'em.
> Index: xfsprogs-dev/repair/scan.c
> ===================================================================
> --- xfsprogs-dev.orig/repair/scan.c 2009-08-21 18:24:26.000000000 +0000
> +++ xfsprogs-dev/repair/scan.c 2009-08-21 18:40:59.000000000 +0000
> @@ -439,15 +439,16 @@ _("out-of-order bmap key (file offset) i
> }
>
> void
> -scanfunc_bno(
> +scanfunc_allocbt(
> struct xfs_btree_block *block,
> int level,
> xfs_agblock_t bno,
> xfs_agnumber_t agno,
> int suspect,
> - int isroot
> - )
> + int isroot,
> + __uint32_t magic)
> {
> + const char *name;
> xfs_agblock_t b, e;
> int i;
> xfs_alloc_ptr_t *pp;
> @@ -456,16 +457,18 @@ scanfunc_bno(
> int numrecs;
> int state;
>
> - if (be32_to_cpu(block->bb_magic) != XFS_ABTB_MAGIC) {
> - do_warn(_("bad magic # %#x in btbno block %d/%d\n"),
> - be32_to_cpu(block->bb_magic), agno, bno);
> + name = (magic == XFS_ABTB_MAGIC) ? "bno" : "cnt";
Should we explicitly test that this is either
XFS_ABTC_MAGIC or XFS_ABTB_MAGIC here to avoid any programming-error
type problems?
> +
> + if (be32_to_cpu(block->bb_magic) != magic) {
> + do_warn(_("bad magic # %#x in bt%s block %d/%d\n"),
> + be32_to_cpu(block->bb_magic), name, agno, bno);
> hdr_errors++;
> if (suspect)
> return;
> }
> if (be16_to_cpu(block->bb_level) != level) {
> - do_warn(_("expected level %d got %d in btbno block %d/%d\n"),
> - level, be16_to_cpu(block->bb_level), agno, bno);
> + do_warn(_("expected level %d got %d in bt%s block %d/%d\n"),
> + level, be16_to_cpu(block->bb_level), name, agno, bno);
> hdr_errors++;
> if (suspect)
> return;
> @@ -483,8 +486,8 @@ scanfunc_bno(
> default:
> set_agbno_state(mp, agno, bno, XR_E_MULT);
> do_warn(
> -_("bno freespace btree block claimed (state %d), agno %d, bno %d, suspect %d\n"),
> - state, agno, bno, suspect);
> +_("%s freespace btree block claimed (state %d), agno %d, bno %d, suspect %d\n"),
> + name, state, agno, bno, suspect);
> return;
> }
>
> @@ -520,15 +523,27 @@ _("bno freespace btree block claimed (st
> continue;
> for (b = be32_to_cpu(rp[i].ar_startblock);
> b < e; b++) {
> - if (get_agbno_state(mp, agno, b)
> - == XR_E_UNKNOWN)
> + state = get_agbno_state(mp, agno, b);
> + switch (state) {
> + case XR_E_UNKNOWN:
> set_agbno_state(mp, agno, b,
> XR_E_FREE1);
> - else {
> + break;
> + case XR_E_FREE1:
> + /*
> + * no warning messages -- we'll catch
> + * FREE1 blocks later
> + */
> + if (magic != XFS_ABTB_MAGIC) {
Why not make this explicitly "if (magic == XFS_ABTC_MAGIC)" - I guess it seems potentially
more future-proof to me though I don't suppose we'll ever get a new type here. :)
The positive test seems clearer to me but *shrug*.
Rest looks fine. I suppose we should do the same to the functions in db/* someday.
Thanks,
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-10-12 16:51 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-02 17:55 [PATCH 00/14] repair memory usage reductions Christoph Hellwig
2009-09-02 17:55 ` [PATCH 01/14] repair: merge scanfunc_bno and scanfunc_cnt Christoph Hellwig
2009-10-12 16:53 ` Eric Sandeen [this message]
2009-10-13 22:13 ` Christoph Hellwig
2009-10-13 23:36 ` Alex Elder
2009-09-02 17:55 ` [PATCH 02/14] repair: reduce byte swap operations in scanfunc_allocbt Christoph Hellwig
2009-10-12 17:18 ` Eric Sandeen
2009-10-13 23:37 ` [PATCH 02/14] repair: reduce byte swap operations inscanfunc_allocbt Alex Elder
2009-09-02 17:55 ` [PATCH 03/14] repair: kill B_IS_META flag Christoph Hellwig
2009-10-12 19:45 ` Eric Sandeen
2009-10-13 22:16 ` Christoph Hellwig
2009-10-13 22:19 ` Eric Sandeen
2009-10-13 23:38 ` Alex Elder
2009-09-02 17:55 ` [PATCH 04/14] repair: split up scanfunc_ino Christoph Hellwig
2009-10-12 20:06 ` Eric Sandeen
2009-10-13 22:19 ` Christoph Hellwig
2009-10-13 22:22 ` Eric Sandeen
2009-10-13 22:23 ` Christoph Hellwig
2009-09-02 17:55 ` [PATCH 05/14] repair: reduce byte swapping in scan_freelist Christoph Hellwig
2009-10-12 20:43 ` Eric Sandeen
2009-09-02 17:55 ` [PATCH 06/14] repair: use a btree instead of a radix tree for the prefetch queue Christoph Hellwig
2009-10-21 17:12 ` [PATCH 06/14] repair: use a btree instead of a radix tree for theprefetch queue Alex Elder
2009-11-12 10:04 ` Christoph Hellwig
2009-11-12 23:46 ` Dave Chinner
2009-09-02 17:55 ` [PATCH 07/14] repair: use single prefetch queue Christoph Hellwig
2009-10-21 17:48 ` Alex Elder
2009-11-12 10:09 ` Christoph Hellwig
2009-09-02 17:55 ` [PATCH 08/14] repair: clean up prefetch tracing Christoph Hellwig
2009-10-21 17:53 ` Alex Elder
2009-09-02 17:55 ` [PATCH 09/14] repair: track logical to physical block mapping more effeciently Christoph Hellwig
2009-10-21 19:06 ` [PATCH 09/14] repair: track logical to physical block mapping moreeffeciently Alex Elder
2009-11-12 10:18 ` Christoph Hellwig
2009-09-02 17:55 ` [PATCH 10/14] repair: cleanup helpers for tracking block usage Christoph Hellwig
2009-10-21 19:33 ` Alex Elder
2009-11-12 10:21 ` Christoph Hellwig
2009-09-02 17:55 ` [PATCH 11/14] repair: cleanup alloc/free/reset of the block usage tracking Christoph Hellwig
2009-10-21 20:22 ` [PATCH 11/14] repair: cleanup alloc/free/reset of the block usagetracking Alex Elder
2009-09-02 17:55 ` [PATCH 12/14] repair: switch block usage bitmap to a btree Christoph Hellwig
2009-10-22 16:22 ` Alex Elder
2009-11-12 10:25 ` Christoph Hellwig
2009-09-02 17:55 ` [PATCH 13/14] repair: optimize duplicate extent tracking Christoph Hellwig
2009-10-22 16:41 ` Alex Elder
2009-09-02 17:55 ` [PATCH 14/14] repair: add missing locking in scanfunc_bmap Christoph Hellwig
2009-10-22 16:42 ` Alex Elder
2009-09-03 20:49 ` [PATCH 00/14] repair memory usage reductions Geoffrey Wehrman
2009-09-04 2:57 ` Dave Chinner
2009-09-04 13:37 ` Geoffrey Wehrman
2009-09-04 14:51 ` Christoph Hellwig
2009-09-04 17:24 ` Michael Monnerie
2009-11-12 15:58 ` Christoph Hellwig
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=4AD35EEC.4080707@sandeen.net \
--to=sandeen@sandeen.net \
--cc=hch@infradead.org \
--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