All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v4 1/9] btrfs: calculate @physical_end using @dev_extent_len directly in scrub_stripe()
Date: Tue, 22 Mar 2022 23:26:19 -0700	[thread overview]
Message-ID: <Yjq9i/o7BEAxjGdH@infradead.org> (raw)
In-Reply-To: <62725efd10680c9c92364021f985865294d3b009.1646984153.git.wqu@suse.com>

On Fri, Mar 11, 2022 at 03:38:41PM +0800, Qu Wenruo wrote:
> @@ -3183,10 +3183,10 @@ static noinline_for_stack int scrub_stripe(struct scrub_ctx *sctx,
>  	int slot;
>  	u64 nstripes;
>  	struct extent_buffer *l;
> -	u64 physical;
> +	u64 physical = map->stripes[stripe_index].physical;
>  	u64 logical;
>  	u64 logic_end;
> -	u64 physical_end;
> +	const u64 physical_end = physical + dev_extent_len;

There isn't really much of a point in marking local variables const.
A a nitpick I'd also move the physical and physical_end declarations
next to other as that helps readability a bit.

Otherwise looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

  reply	other threads:[~2022-03-23  6:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11  7:38 [PATCH v4 0/9] btrfs: refactor scrub entrances for each profile Qu Wenruo
2022-03-11  7:38 ` [PATCH v4 1/9] btrfs: calculate @physical_end using @dev_extent_len directly in scrub_stripe() Qu Wenruo
2022-03-23  6:26   ` Christoph Hellwig [this message]
2022-03-11  7:38 ` [PATCH v4 2/9] btrfs: introduce a helper to locate an extent item Qu Wenruo
2022-03-23  6:27   ` Christoph Hellwig
2022-03-23  7:01     ` Qu Wenruo
2022-03-11  7:38 ` [PATCH v4 3/9] btrfs: introduce dedicated helper to scrub simple-mirror based range Qu Wenruo
2022-03-11  7:38 ` [PATCH v4 4/9] btrfs: introduce dedicated helper to scrub simple-stripe " Qu Wenruo
2022-03-11  7:38 ` [PATCH v4 5/9] btrfs: scrub: cleanup the non-RAID56 branches in scrub_stripe() Qu Wenruo
2022-03-11  7:38 ` [PATCH v4 6/9] btrfs: use scrub_simple_mirror() to handle RAID56 data stripe scrub Qu Wenruo
2022-03-11  7:38 ` [PATCH v4 7/9] btrfs: refactor scrub_raid56_parity() Qu Wenruo
2022-03-11  7:38 ` [PATCH v4 8/9] btrfs: use find_first_extent_item() to replace the open-coded extent item search Qu Wenruo
2022-03-11  7:38 ` [PATCH v4 9/9] btrfs: move scrub_remap_extent() call into scrub_extent() with more comments Qu Wenruo
2022-03-15  7:02 ` [PATCH v4 0/9] btrfs: refactor scrub entrances for each profile Qu Wenruo
2022-04-20 21:16   ` David Sterba
2022-04-27 19:10     ` David Sterba

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=Yjq9i/o7BEAxjGdH@infradead.org \
    --to=hch@infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.