All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
To: fdmanana@gmail.com
Cc: Wang Shilong <wangshilong1991@gmail.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 3/3] Btrfs: fix missing inline refs when walking backrefs
Date: Mon, 13 Jan 2014 09:27:49 +0800	[thread overview]
Message-ID: <52D34115.7010605@cn.fujitsu.com> (raw)
In-Reply-To: <CAL3q7H66_b9qZFtT6sU7Ao0-xGbQJncmGFJ8h6x=8jHF9uMpUw@mail.gmail.com>

Hi Filipe,

On 01/12/2014 11:36 PM, Filipe David Manana wrote:
> On Sun, Jan 12, 2014 at 1:38 PM, Wang Shilong <wangshilong1991@gmail.com> wrote:
>> From: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
>>
>> If @slot=0, we may have an expected item in the previous leaf,
>> So we should handle that case, otherwise, we will miss inline refs
>> ,fix it.
> Hi Shilong.
>
> How can this happen exactly?
>
> So the search key, regardless of having an BTRFS_EXTENT_ITEM_KEY or  a
> BTRFS_METADATA_ITEM_KEY type, always has an offset set to (u64)-1.
> This means the btrfs_search_slot call will always return 1 (not found,
> as expected) or an error.
>
> And btrfs_search_slot, when it doesn't find a key and if that key
> should be the first item in a leaf, it makes the path point to the
> previous leaf with a "path->slots[0] ==
> btrfs_header_nritems(path->nodes[0])" (see [1]), otherwise to some
> value > 0. The only cases I can imagine getting "path->slots[0] == 0"
> is if we hit the first, i.e. left most, leaf in the btree or if the
> btree consists only of 1 leaf (no nodes) - in these cases there's
> isn't a previous leaf.
>
> Did I miss something here?
>
> thanks
>
> [1] - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/ctree.c?id=refs/tags/v3.13-rc8#n2629
You are right, i was missing something when i made this patch.
Really thanks for you reviewing and correcting me!:-)

Thanks,
Wang
>
>> Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
>> ---
>>   fs/btrfs/backref.c | 13 ++++++-------
>>   1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
>> index 964679c..4ccd726 100644
>> --- a/fs/btrfs/backref.c
>> +++ b/fs/btrfs/backref.c
>> @@ -893,14 +893,13 @@ again:
>>                  spin_unlock(&delayed_refs->lock);
>>          }
>>
>> -       if (path->slots[0]) {
>> -               struct extent_buffer *leaf;
>> -               int slot;
>> +       ret = btrfs_previous_extent_item(fs_info->extent_root, path,
>> +                                        key.objectid);
>> +       if (ret < 0)
>> +               goto out;
>>
>> -               path->slots[0]--;
>> -               leaf = path->nodes[0];
>> -               slot = path->slots[0];
>> -               btrfs_item_key_to_cpu(leaf, &key, slot);
>> +       if (ret == 0) {
>> +               btrfs_item_key_to_cpu(path->nodes[0], &key, path->slots[0]);
>>                  if (key.objectid == bytenr &&
>>                      (key.type == BTRFS_EXTENT_ITEM_KEY ||
>>                       key.type == BTRFS_METADATA_ITEM_KEY)) {
>> --
>> 1.8.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>


      reply	other threads:[~2014-01-13  1:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-12 13:38 [PATCH] Btrfs: do not use extent commit root for sending Wang Shilong
2014-01-12 13:38 ` [PATCH 1/3] Btrfs: fix missing skinny metadata check in scrub_stripe() Wang Shilong
2014-01-12 13:38 ` [PATCH 2/3] Btrfs: fix to search previous metadata extent item since skinny metadata Wang Shilong
2014-01-12 13:38 ` [PATCH 3/3] Btrfs: fix missing inline refs when walking backrefs Wang Shilong
2014-01-12 15:36   ` Filipe David Manana
2014-01-13  1:27     ` Wang Shilong [this message]

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=52D34115.7010605@cn.fujitsu.com \
    --to=wangsl.fnst@cn.fujitsu.com \
    --cc=fdmanana@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wangshilong1991@gmail.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.