All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: damenly.su@gmail.com, linux-btrfs@vger.kernel.org
Cc: suy.fnst@cn.fujitsu.com
Subject: Re: [PATCH v2 5/7] btrfs-progs: lowmem: continue to check item in last slot while checking inodes
Date: Fri, 14 Sep 2018 07:43:01 +0800	[thread overview]
Message-ID: <e415c063-772b-3dca-fdd1-ed88c90caf8b@gmx.com> (raw)
In-Reply-To: <20180912204924.10089-6-suy.fnst@cn.fujitsu.com>



On 2018/9/13 上午4:49, damenly.su@gmail.com wrote:
> From: Su Yue <suy.fnst@cn.fujitsu.com>
> 
> After call of check_inode_item(), path may point to the last unchecked
> slot of the leaf. The outer walk_up_tree() always treats the position
> as checked item then skips to next item.

So check_inode_item() always set its path to *unchecked* slot, while
walk_up_tree() always think its path is set to *checked* slot.

Then this is indeed a problem.

> 
> If the last item was an inode item, yes, it was unchecked.
> Then walk_up_tree() will think the leaf is checked and walk up to
> upper node, process_one_leaf() in walk_down_tree() would skip to
> check next inode item. Which means, the inode item won't be checked.
> 
> Solution:
> After check_inode_item returns, if found path point to the last item
> of a leaf,

Would you please explain more about why last item makes a difference here?

>From previous statement, it looks like it's the difference in how
walk_up_tree() and check_inode_item() handles the path.
Not really related to last item.

Or did I miss something?

Thanks,
Qu

> decrease path slot manually, so walk_up_tree() will stay
> on the leaf.
> 
> Fixes: 5e2dc770471b ("btrfs-progs: check: skip shared node or leaf check for low_memory mode")
> Signed-off-by: Su Yue <suy.fnst@cn.fujitsu.com>
> ---
>  check/mode-lowmem.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/check/mode-lowmem.c b/check/mode-lowmem.c
> index 8fc9edab1d66..b6b33786d02b 100644
> --- a/check/mode-lowmem.c
> +++ b/check/mode-lowmem.c
> @@ -2612,6 +2612,18 @@ again:
>  	if (cur->start == cur_bytenr)
>  		goto again;
>  
> +	/*
> +	 * path may point at the last item(a inode item maybe) in a leaf.
> +	 * Without below lines, walk_up_tree() will skip the item which
> +	 * means all items related to the inode will never be checked.
> +	 * Decrease the slot manually, walk_up_tree won't skip to next node
> +	 * if it occurs.
> +	 */
> +	if (path->slots[0] + 1 >= btrfs_header_nritems(path->nodes[0])) {
> +		if (path->slots[0])
> +			path->slots[0]--;
> +	}
> +
>  	/*
>  	 * we have switched to another leaf, above nodes may
>  	 * have changed, here walk down the path, if a node
> 

  reply	other threads:[~2018-09-14  4:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12 20:49 [PATCH v2 0/7] btrfs-progs: lowmem: bug fixes and inode_extref repair damenly.su
2018-09-12 20:49 ` [PATCH v2 1/7] btrfs-progs: adjust arguments of btrfs_lookup_inode_extref() damenly.su
2018-09-13 23:26   ` Qu Wenruo
2018-09-12 20:49 ` [PATCH v2 2/7] btrfs-progs: make btrfs_unlink() lookup inode_extref damenly.su
2018-09-13 23:30   ` Qu Wenruo
2018-09-12 20:49 ` [PATCH v2 3/7] btrfs-progs: lowmem check: find dir_item by di_key in check_dir_item() damenly.su
2018-09-13 23:33   ` Qu Wenruo
2018-09-14  0:57     ` Su Yue
2018-09-12 20:49 ` [PATCH v2 4/7] btrfs-progs: lowmem: search key of root again after check_fs_root() under repair damenly.su
2018-09-13 23:37   ` Qu Wenruo
2018-09-14  0:58     ` Su Yue
2018-09-14  6:27       ` Nikolay Borisov
2018-09-14  7:13         ` Su Yue
2018-09-12 20:49 ` [PATCH v2 5/7] btrfs-progs: lowmem: continue to check item in last slot while checking inodes damenly.su
2018-09-13 23:43   ` Qu Wenruo [this message]
2018-09-14  1:22     ` Su Yue
2018-09-12 20:49 ` [PATCH v2 6/7] btrfs-progs: lowmem: improve check_inode_extref() damenly.su
2018-09-13 23:50   ` Qu Wenruo
2018-09-12 20:49 ` [PATCH v2 7/7] btrfs-progs: fsck-tests: add test case inode_extref without dir_item and dir_index damenly.su
2018-09-13 23:55   ` 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=e415c063-772b-3dca-fdd1-ed88c90caf8b@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=damenly.su@gmail.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.