linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>, Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 1/3] btrfs: backref: Introduce the skeleton of btrfs_backref_iterator
Date: Fri, 14 Feb 2020 11:36:45 +0200	[thread overview]
Message-ID: <9a4ded8d-929c-4081-2033-b923a4639087@suse.com> (raw)
In-Reply-To: <1f17ed5b-978e-8a45-813d-3fdce61a8e9c@gmx.com>



On 14.02.20 г. 11:33 ч., Qu Wenruo wrote:
> 
> 
> On 2020/2/14 下午5:19, Nikolay Borisov wrote:
>>
>>
>> On 14.02.20 г. 10:13 ч., Qu Wenruo wrote:
>>> Due to the complex nature of btrfs extent tree, when we want to iterate
>>> all backrefs of one extent, it involves quite a lot of works, like
>>> search the EXTENT_ITEM/METADATA_ITEM, iteration through inline and keyed
>>> backrefs.
>>>
>>> Normally this would result pretty complex code, something like:
>>>   btrfs_search_slot()
>>>   /* Ensure we are at EXTENT_ITEM/METADATA_ITEM */
>>>   while (1) {	/* Loop for extent tree items */
>>> 	while (ptr < end) { /* Loop for inlined items */
>>> 		/* REAL WORK HERE */
>>> 	}
>>>   next:
>>>   	ret = btrfs_next_item()
>>> 	/* Ensure we're still at keyed item for specified bytenr */
>>>   }
>>>
>>> The idea of btrfs_backref_iterator is to avoid such complex and hard to
>>> read code structure, but something like the following:
>>>
>>>   iterator = btrfs_backref_iterator_alloc();
>>>   ret = btrfs_backref_iterator_start(iterator, bytenr);
>>>   if (ret < 0)
>>> 	goto out;
>>>   for (; ; ret = btrfs_backref_iterator_next(iterator)) {
>>> 	/* REAL WORK HERE */
>>>   }
>>>   out:
>>>   btrfs_backref_iterator_free(iterator);
>>>
>>> This patch is just the skeleton + btrfs_backref_iterator_start() code.
>>>
>>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>>> ---
>>>  fs/btrfs/backref.c | 58 +++++++++++++++++++++++++++++++++++
>>>  fs/btrfs/backref.h | 76 ++++++++++++++++++++++++++++++++++++++++++++++
>>>  2 files changed, 134 insertions(+)
>>>
>>> diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
>>> index e5d85311d5d5..73c4829609c9 100644
>>> --- a/fs/btrfs/backref.c
>>> +++ b/fs/btrfs/backref.c
>>> @@ -2252,3 +2252,61 @@ void free_ipath(struct inode_fs_paths *ipath)
>>>  	kvfree(ipath->fspath);
>>>  	kfree(ipath);
>>>  }
>>> +
>>> +int btrfs_backref_iterator_start(struct btrfs_backref_iterator *iterator,
>>> +				 u64 bytenr)
>>> +{
>>> +	struct btrfs_fs_info *fs_info = iterator->fs_info;
>>> +	struct btrfs_path *path = iterator->path;
>>> +	struct btrfs_extent_item *ei;
>>> +	struct btrfs_key key;
>>> +	int ret;
>>> +
>>> +	key.objectid = bytenr;
>>> +	key.type = BTRFS_METADATA_ITEM_KEY;
>>> +	key.offset = (u64)-1;
>>> +
>>> +	ret = btrfs_search_slot(NULL, fs_info->extent_root, &key, path, 0, 0);
>>> +	if (ret < 0)
>>> +		return ret;
>>> +	if (ret == 0) {
>>> +		ret = -EUCLEAN;
>>> +		goto release;
>>> +	}
>>> +	if (path->slots[0] == 0) {
>>> +		WARN_ON(IS_ENABLED(CONFIG_BTRFS_DEBUG));
>>> +		ret = -EUCLEAN;
>>> +		goto release;
>>> +	}
>>> +	path->slots[0]--;
>>> +
>>> +	btrfs_item_key_to_cpu(path->nodes[0], &key, path->slots[0]);
>>> +	if (!(key.type == BTRFS_EXTENT_ITEM_KEY ||
>>> +	      key.type == BTRFS_METADATA_ITEM_KEY) || key.objectid != bytenr) {
>>> +		ret = -ENOENT;
>>> +		goto release;
>>> +	}
>>> +	memcpy(&iterator->cur_key, &key, sizeof(key));
>>> +	iterator->end_ptr = btrfs_item_end_nr(path->nodes[0], path->slots[0]);
>>> +	iterator->item_ptr = btrfs_item_ptr_offset(path->nodes[0],
>>> +						   path->slots[0]);
>>> +	ei = btrfs_item_ptr(path->nodes[0], path->slots[0],
>>> +			    struct btrfs_extent_item);
>>> +
>>> +	/* Only support iteration on tree backref yet */
>>> +	if (btrfs_extent_flags(path->nodes[0], ei) & BTRFS_EXTENT_FLAG_DATA) {
>>> +		ret = -ENOTTY;
>>> +		goto release;
>>> +	}
>>
>> Isn't this implied bye the fact you are searching for METADATA ITEMS to
>> begin with ? Considering this shouldn't detecting EXTENT_FLAG_DATA in
>> the backrefs of a METADATA_EXTENT be considered a corruption?
> 
> For non skinny-metadata fs, we can hit with EXTENT_ITEM.
> So it's still possible to hit a corruption undetected by tree-checker.
> 
> But you're right, we shouldn't really hit a data extent here, as
> previous loops have excluded all data extents.

Then put a comment saying this is done as an extra precaution.

<split>

  reply	other threads:[~2020-02-14  9:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-14  8:13 [PATCH v2 0/3] Btrfs: relocation: Refactor build_backref_tree() using btrfs_backref_iterator infrastructure Qu Wenruo
2020-02-14  8:13 ` [PATCH v2 1/3] btrfs: backref: Introduce the skeleton of btrfs_backref_iterator Qu Wenruo
2020-02-14  8:53   ` Johannes Thumshirn
2020-02-14  9:19   ` Nikolay Borisov
2020-02-14  9:33     ` Qu Wenruo
2020-02-14  9:36       ` Nikolay Borisov [this message]
2020-02-14  9:24   ` Nikolay Borisov
2020-02-14  9:34     ` Qu Wenruo
2020-02-14  8:13 ` [PATCH v2 2/3] btrfs: backref: Implement btrfs_backref_iterator_next() Qu Wenruo
2020-02-14  9:25   ` Nikolay Borisov
2020-02-14  9:28     ` Nikolay Borisov
2020-02-14  9:35     ` Qu Wenruo
2020-02-14  8:13 ` [PATCH v2 3/3] btrfs: relocation: Use btrfs_backref_iterator infrastructure Qu Wenruo
2020-02-14  9:00   ` Johannes Thumshirn
2020-02-14  9:36     ` Qu Wenruo
2020-02-14  9:29   ` Nikolay Borisov

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=9a4ded8d-929c-4081-2033-b923a4639087@suse.com \
    --to=nborisov@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).