| Message ID | 265f9914e5f66686647a716a7a038de81bb09aec.1665143843.git.wqu@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | btrfs-progs: mkfs: extent-tree-v2 related fixes | expand |
On 10/7/22 20:03, Qu Wenruo wrote: > [BUG] > When enabling extent-tree-v2 feature at mkfs time (need to enable > experimental features), mkfs.btrfs will crash: > > # ./mkfs.btrfs -f -O extent-tree-v2 ~/test.img > btrfs-progs v5.19.1 > See http://btrfs.wiki.kernel.org for more information. > > ERROR: superblock magic doesn't match > NOTE: several default settings have changed in version 5.15, please make sure > this does not affect your deployments: > - DUP for metadata (-m dup) > - enabled no-holes (-O no-holes) > - enabled free-space-tree (-R free-space-tree) > > Segmentation fault (core dumped) > > [CAUSE] > The block group tree looks like this after make_btrfs() call: > > (gdb) call btrfs_print_tree(root->fs_info->block_group_root->node, 0) > leaf 1163264 items 1 free space 16234 generation 1 owner BLOCK_GROUP_TREE > leaf 1163264 flags 0x0() backref revision 1 > checksum stored f137c1ac > checksum calced f137c1ac > fs uuid 450d4b15-4954-4574-9801-8c6d248aaec6 > chunk uuid 4c4cc54d-f240-4aa4-b88b-bd487db43444 > item 0 key (1048576 BLOCK_GROUP_ITEM 4194304) itemoff 16259 itemsize 24 > block group used 131072 chunk_objectid 256 flags SYSTEM|single > ^^^ > > This looks completely sane, but notice that chunk_objectid 256. > That 256 value is the expected one for regular non-extent-tree-v2 btrfs, > but for extent-tree-v2, chunk_objectid is reused as the global id of > extent tree where the block group belongs to. > > With the old 256 value as chunk_objectid, btrfs will not find an extent > tree root for the block group, and return NULL for btrfs_extent_root() > call, and trigger segfault. > > This is a regression caused by commit 1430b41427b5 ("btrfs-progs: > separate block group tree from extent tree v2"), which doesn't take > extent-tree-v2 on-disk format into consideration. > > [FIX] > For the initial btrfs created by make_btrfs(), all block group items > will be in extent-tree global id 0, thus we can reset chunk_objectid to > 0, if and only if extent-tree-v2 is enabled. > > Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Tested-by: Anand Jain <anand.jain@oracle.com>
diff --git a/mkfs/common.c b/mkfs/common.c index 3a517a503e61..d77688ba584d 100644 --- a/mkfs/common.c +++ b/mkfs/common.c @@ -227,12 +227,22 @@ static int create_block_group_tree(int fd, struct btrfs_mkfs_config *cfg, u64 bg_offset, u64 bg_size, u64 bg_used) { int ret; + u64 chunk_objectid = BTRFS_FIRST_CHUNK_TREE_OBJECTID; + + /* + * For extent-tree-v2, chunk_objectid of block group item is reused + * to indicate which extent-tree the block group is in. + * + * Thus for the initial image, we should set the chunk_objectid to 0, + * as all initial bgs are in the extent tree with global id 0. + */ + if (cfg->features.incompat_flags & BTRFS_FEATURE_INCOMPAT_EXTENT_TREE_V2) + chunk_objectid = 0; memset(buf->data + sizeof(struct btrfs_header), 0, cfg->nodesize - sizeof(struct btrfs_header)); write_block_group_item(buf, 0, bg_offset, bg_size, bg_used, - BTRFS_FIRST_CHUNK_TREE_OBJECTID, - cfg->leaf_data_size - + chunk_objectid, cfg->leaf_data_size - sizeof(struct btrfs_block_group_item)); btrfs_set_header_bytenr(buf, cfg->blocks[MKFS_BLOCK_GROUP_TREE]); btrfs_set_header_owner(buf, BTRFS_BLOCK_GROUP_TREE_OBJECTID);
[BUG] When enabling extent-tree-v2 feature at mkfs time (need to enable experimental features), mkfs.btrfs will crash: # ./mkfs.btrfs -f -O extent-tree-v2 ~/test.img btrfs-progs v5.19.1 See http://btrfs.wiki.kernel.org for more information. ERROR: superblock magic doesn't match NOTE: several default settings have changed in version 5.15, please make sure this does not affect your deployments: - DUP for metadata (-m dup) - enabled no-holes (-O no-holes) - enabled free-space-tree (-R free-space-tree) Segmentation fault (core dumped) [CAUSE] The block group tree looks like this after make_btrfs() call: (gdb) call btrfs_print_tree(root->fs_info->block_group_root->node, 0) leaf 1163264 items 1 free space 16234 generation 1 owner BLOCK_GROUP_TREE leaf 1163264 flags 0x0() backref revision 1 checksum stored f137c1ac checksum calced f137c1ac fs uuid 450d4b15-4954-4574-9801-8c6d248aaec6 chunk uuid 4c4cc54d-f240-4aa4-b88b-bd487db43444 item 0 key (1048576 BLOCK_GROUP_ITEM 4194304) itemoff 16259 itemsize 24 block group used 131072 chunk_objectid 256 flags SYSTEM|single ^^^ This looks completely sane, but notice that chunk_objectid 256. That 256 value is the expected one for regular non-extent-tree-v2 btrfs, but for extent-tree-v2, chunk_objectid is reused as the global id of extent tree where the block group belongs to. With the old 256 value as chunk_objectid, btrfs will not find an extent tree root for the block group, and return NULL for btrfs_extent_root() call, and trigger segfault. This is a regression caused by commit 1430b41427b5 ("btrfs-progs: separate block group tree from extent tree v2"), which doesn't take extent-tree-v2 on-disk format into consideration. [FIX] For the initial btrfs created by make_btrfs(), all block group items will be in extent-tree global id 0, thus we can reset chunk_objectid to 0, if and only if extent-tree-v2 is enabled. Signed-off-by: Qu Wenruo <wqu@suse.com> --- mkfs/common.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)