From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Alex Lyakas <alex.btrfs@zadarastorage.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] btrfs-progs: rebuild missing block group during chunk recovery if possible
Date: Wed, 24 Dec 2014 16:52:52 +0800 [thread overview]
Message-ID: <549A7EE4.8000705@cn.fujitsu.com> (raw)
In-Reply-To: <CAOcd+r0tYszrTBgx0mTHMQRO7oi-zXfX4bCpv8rUTDcpAi4Meg@mail.gmail.com>
-------- Original Message --------
Subject: Re: [PATCH] btrfs-progs: rebuild missing block group during
chunk recovery if possible
From: Alex Lyakas <alex.btrfs@zadarastorage.com>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Date: 2014年12月24日 16:49
> Hi Qu,
>
> On Wed, Dec 24, 2014 at 3:09 AM, Qu Wenruo <quwenruo@cn.fujitsu.com> wrote:
>> -------- Original Message --------
>> Subject: Re: [PATCH] btrfs-progs: rebuild missing block group during chunk
>> recovery if possible
>> From: Alex Lyakas <alex.btrfs@zadarastorage.com>
>> To: Qu Wenruo <quwenruo@cn.fujitsu.com>
>> Date: 2014年12月24日 00:49
>>> Hi Qu,
>>>
>>> On Thu, Oct 30, 2014 at 4:54 AM, Qu Wenruo <quwenruo@cn.fujitsu.com>
>>> wrote:
>>>> [snipped]
>>>> +
>>>> +static int __insert_block_group(struct btrfs_trans_handle *trans,
>>>> + struct chunk_record *chunk_rec,
>>>> + struct btrfs_root *extent_root,
>>>> + u64 used)
>>>> +{
>>>> + struct btrfs_block_group_item bg_item;
>>>> + struct btrfs_key key;
>>>> + int ret = 0;
>>>> +
>>>> + btrfs_set_block_group_used(&bg_item, used);
>>>> + btrfs_set_block_group_chunk_objectid(&bg_item, used);
>>> This looks like a bug. Instead of "used", I think it should be
>>> "BTRFS_FIRST_CHUNK_TREE_OBJECTID".
>> Oh, my mistake, BTRFS_FIRST_CHUNK_TREE_OBJECTID is right.
>> Thanks for pointing out this.
>>>
>>>> [snipped]
>>>> --
>>>> 2.1.2
>>> Couple of questions:
>>> # In remove_chunk_extent_item, should we also consider "rebuild"
>>> chunks now? It can happen that a "rebuild" chunks is a SYSTEM chunk.
>>> Should we try to handle it as well?
>> Not quite sure about the meaning of "rebuild" here.
>> The chunk-recovery has the rebuild_chunk_tree() function to rebuild the
>> whole chunk tree with
>> the good/repaired chunks we found.
>>> # Same question for "rebuild_sys_array". Should we also consider
>>> "rebuild" chunks?
>> The chunk-recovery has rebuild_sys_array() to handle SYSTEM chunk too.
>>
> I meant that with this patch you have added "rebuild_chunks" list:
> struct list_head good_chunks;
> struct list_head bad_chunks;
> struct list_head rebuild_chunks; <--- you added this
> struct list_head unrepaired_chunks;
Oh, now I understand it.
>
>
> These are chunks that have no block-group record, but we are confident
> that we can rebuild the block-group records for these chunks by
> scanning all EXTENT_ITEMs in the block-group range and calculating the
> "used" value for the block-group. If we fail, we just set
> used==block-group size. My question is: should we now consider those
> "rebuild_chunks" same as "good_chunks"? I.e., should we also consider
> those chunks in the following functions:
> - remove_chunk_extent_item: probably no, because we need the
> EXTENT_ITEMs to recalculate the "used" value
Yep, no need to remove extents.
> - rebuild_sys_array: if it happens that a "rebuild_chunk" is also a
> SYSTEM chunk, should we add it to the sys_chunk_array too? (In
> addition to good_chunks).
That's right, it should be added to SYSTEM chunks.
Great thanks for reviewing and pointing out this!
Thanks,
Qu
>
> Thanks,
> Alex.
>
>
>> Thanks,
>> Qu
>>
>>> Thanks,
>>> Alex.
>>>
>>>
>>>
>>>> --
>>>> 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
>>
prev parent reply other threads:[~2014-12-24 8:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-30 2:54 [PATCH] btrfs-progs: rebuild missing block group during chunk recovery if possible Qu Wenruo
2014-12-23 16:49 ` Alex Lyakas
2014-12-24 1:09 ` Qu Wenruo
2014-12-24 8:49 ` Alex Lyakas
2014-12-24 8:52 ` Qu Wenruo [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=549A7EE4.8000705@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=alex.btrfs@zadarastorage.com \
--cc=linux-btrfs@vger.kernel.org \
/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).