All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Su Yue <suy.fnst@cn.fujitsu.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 03/13] btrfs-progs: lowmem: fix false alert if extent item has been repaired
Date: Tue, 23 Oct 2018 18:30:58 +0800	[thread overview]
Message-ID: <3363e342-9acc-95d4-cf70-2872fc8b6258@gmx.com> (raw)
In-Reply-To: <20181023094147.7906-4-suy.fnst@cn.fujitsu.com>



On 2018/10/23 下午5:41, Su Yue wrote:
> Previously, @err are assigned immediately after check but before
> repair.
> repair_extent_item()'s return value also confuses the caller. If
> error has been repaired and returns 0, check_extent_item() will try
> to continue check the nonexistent and cause flase alerts.
> 
> Here make repair_extent_item()'s return codes only represents status
> of the extent item, error bits are passed by pointer.
> Move the change of @err after repair.
> 
> Signed-off-by: Su Yue <suy.fnst@cn.fujitsu.com>
> ---
>  check/mode-lowmem.c | 106 ++++++++++++++++++++++++++++----------------
>  1 file changed, 68 insertions(+), 38 deletions(-)
> 
> diff --git a/check/mode-lowmem.c b/check/mode-lowmem.c
> index 76e7be81ceb1..769b3141de8b 100644
> --- a/check/mode-lowmem.c
> +++ b/check/mode-lowmem.c
> @@ -3788,35 +3788,35 @@ out:
>  /*
>   * Only delete backref if REFERENCER_MISSING now
>   *
> - * Returns <0   the extent was deleted
> - * Returns >0   the backref was deleted but extent still exists, returned value
> - *               means error after repair
> + * Returns <0   the whole extent item was deleted
> + * Returns >0   the backref was deleted but extent still exists, @err_ret
> + *		will be set to be error bits after repair.

Well, I have to admit the parameter list is really human friendly from
the initial design.

In fact, the only real user of @err is just that "if ((err &
(REFERENCER_MISSING | REFERENCER_MISMATCH)) == 0)" line.

We can in fact get rid of that @err parameter and do that check at the
only caller of repair_extent_item().


And then redefine the return value.

Like "Return < 0 if we failed to repair backref for the extent.
Return 0 if we repaired the backref for the extent".

[snip]
>  
> -	if (err && repair) {
> +	if (tmp_err && repair) {
>  		ret = repair_extent_item(fs_info->extent_root, path,
>  			 key.objectid, num_bytes, parent, root_objectid,
> -			 owner, owner_offset, ret);
> -		if (ret < 0)

If follow my above method, here the code can be a little easier:
	if (tmp_err && repair) {
		if (!(tmp_err & (REFERENCER_MISSING |
		    REFENCER_MISMATCH)) {
			err |= tmp_err;
			goto next;
		}
		ret = repair_extent_item(...);
		if (ret < 0)
			err |= tmp_err;
	} else if (tmp_err) {
		err |= tmp_err;
	}

Without the need to passing @err into repair_extent_item() nor modifying
@err in that function.

Thanks,
Qu

> +			 owner, owner_offset, &tmp_err);
> +		err |= tmp_err;
> +
> +		if (tmp_err & FATAL_ERROR || ret < 0)
>  			goto out;
> -		if (ret) {
> +		/*
> +		 * the error has been repaired which means the extent item
> +		 * is still existed with other backrefs, go to check next.
> +		 */> +		if (ret > 0) {
> +			eb = path->nodes[0];
> +			slot = path->slots[0];
> +			ei = btrfs_item_ptr(eb, slot, struct btrfs_extent_item);
> +			item_size = btrfs_item_size_nr(eb, slot);
>  			goto next;
> -			err = ret;
>  		}
> +	} else {
> +		err |= tmp_err;
>  	}
>  
> -	ptr += btrfs_extent_inline_ref_size(type);
> +	ptr_offset += btrfs_extent_inline_ref_size(type);
>  	goto next;
>  
>  out:
> 

  reply	other threads:[~2018-10-23 10:31 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-23  9:41 [PATCH 00/13] btrfs-progs: fixes of file extent in original and lowmem check Su Yue
2018-10-23  9:41 ` [PATCH 01/13] btrfs-progs: lowmem: add argument path to punch_extent_hole() Su Yue
2018-10-23 10:04   ` Qu Wenruo
2018-10-24  1:18     ` Su Yue
2018-12-02 14:34   ` [PATCH v2 " damenly.su
2018-10-23  9:41 ` [PATCH 02/13] btrfs-progs: lowmem: move nbytes check before isize check Su Yue
2018-10-23 10:07   ` Qu Wenruo
2018-12-02 14:38   ` [PATCH v2 " damenly.su
2018-10-23  9:41 ` [PATCH 03/13] btrfs-progs: lowmem: fix false alert if extent item has been repaired Su Yue
2018-10-23 10:30   ` Qu Wenruo [this message]
2018-10-24  1:27     ` Su Yue
2018-10-24  1:24       ` Qu Wenruo
2018-12-02 14:45   ` [PATCH v2 " damenly.su
2018-10-23  9:41 ` [PATCH 04/13] btrfs-progs: lowmem: fix false alert about the existence of gaps in the check_file_extent Su Yue
2018-10-24  0:13   ` Qu Wenruo
2018-10-23  9:41 ` [PATCH 05/13] btrfs-progs: lowmem: check unaligned disk_bytenr for extent_data Su Yue
2018-10-24  0:13   ` Qu Wenruo
2018-10-23  9:41 ` [PATCH 06/13] btrfs-progs: lowmem: rename delete_extent_tree_item() to delete_item() Su Yue
2018-10-24  0:15   ` Qu Wenruo
2018-10-23  9:41 ` [PATCH 07/13] btrfs-progs: lowmem: delete unaligned bytes extent data under repair Su Yue
2018-10-24  0:16   ` Qu Wenruo
2018-10-23  9:41 ` [PATCH 08/13] btrfs-progs: Revert "btrfs-progs: Add repair and report function for orphan file extent." Su Yue
2018-10-24  0:28   ` Qu Wenruo
2018-10-23  9:41 ` [PATCH 09/13] btrfs-progs: Revert "btrfs-progs: Record orphan data extent ref to corresponding root." Su Yue
2018-10-24  0:29   ` Qu Wenruo
2018-11-07  9:09     ` Su Yanjun <suyj.fnst@cn.fujitsu.com>
2018-11-07  9:14       ` Qu Wenruo
2018-10-23  9:41 ` [PATCH 10/13] btrfs-progs: check: fix bug in find_possible_backrefs Su Yue
2018-10-24  0:34   ` Qu Wenruo
2018-11-07  6:28     ` Su Yanjun <suyj.fnst@cn.fujitsu.com>
2018-11-07  6:40       ` Qu Wenruo
2018-10-23  9:41 ` [PATCH 11/13] btrfs-progs: check: Delete file extent item with unaligned extent backref Su Yue
2018-10-24  0:45   ` Qu Wenruo
2018-11-07  6:21     ` Su Yanjun <suyj.fnst@cn.fujitsu.com>
2018-11-07  6:38       ` Qu Wenruo
2018-11-07  7:04         ` Su Yanjun <suyj.fnst@cn.fujitsu.com>
2018-11-07  7:13           ` Qu Wenruo
2018-10-23  9:41 ` [PATCH 12/13] btrfs-progs: tests: add case for inode lose one file extent Su Yue
2018-10-23  9:41 ` [PATCH 13/13] btrfs-progs: fsck-test: enable lowmem repair for case 001 Su Yue
2018-10-23  9:45 ` [PATCH 00/13] btrfs-progs: fixes of file extent in original and lowmem check Qu Wenruo

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=3363e342-9acc-95d4-cf70-2872fc8b6258@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=suy.fnst@cn.fujitsu.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.