All of lore.kernel.org
 help / color / mirror / Atom feed
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 09:09:24 +0800	[thread overview]
Message-ID: <549A1244.2000309@cn.fujitsu.com> (raw)
In-Reply-To: <CAOcd+r3PxsecRaHOe1RLbxEhWubdy2dzUmE65BDkvmcgb7_9tw@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日 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.

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


  reply	other threads:[~2014-12-24  1:09 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 [this message]
2014-12-24  8:49     ` Alex Lyakas
2014-12-24  8:52       ` 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=549A1244.2000309@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 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.