-------- Original Message --------
Subject: Re: [PATCH] btrfs-progs: rebuild missing block group during
chunk recovery if possible
From: Alex Lyakas <alex.btrfs@xxxxxxxxxxxxxxxxx>
To: Qu Wenruo <quwenruo@xxxxxxxxxxxxxx>
Date: 2014年12月24日 00:49
Hi Qu,
On Thu, Oct 30, 2014 at 4:54 AM, Qu Wenruo <quwenruo@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html