public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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

  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