]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
btrfs: handle setting up relocation of block group with remap-tree
authorMark Harmstone <mark@harmstone.com>
Wed, 7 Jan 2026 14:09:11 +0000 (14:09 +0000)
committerDavid Sterba <dsterba@suse.com>
Tue, 3 Feb 2026 06:54:35 +0000 (07:54 +0100)
commitb56f35560b82e7f8d79aa9ee72720b06639a473c
tree9d162e4d89534e618b73b5695269679b4416fd8a
parent979e1dc3d69e4c825eec05d05d9567b251f6ec23
btrfs: handle setting up relocation of block group with remap-tree

Handle the preliminary work for relocating a block group in a filesystem
with the remap-tree flag set.

If the block group is SYSTEM btrfs_relocate_block_group() proceeds as it
does already, as bootstrapping issues mean that these block groups have
to be processed the existing way. Similarly with METADATA_REMAP blocks, which
are dealt with in a later patch.

Otherwise we walk the free-space tree for the block group in question,
recording any holes. These get converted into identity remaps and placed
in the remap tree, and the block group's REMAPPED flag is set. From now
on no new allocations are possible within this block group, and any I/O
to it will be funnelled through btrfs_translate_remap(). We store the
number of identity remaps in `identity_remap_count`, so that we know
when we've removed the last one and the block group is fully remapped.

The change in btrfs_read_roots() is because data relocations no longer
rely on the data reloc tree as a hidden subvolume in which to do
snapshots.

(Thanks to Sun YangKai for his suggestions.)

Reviewed-by: Boris Burkov <boris@bur.io>
Signed-off-by: Mark Harmstone <mark@harmstone.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/block-group.c
fs/btrfs/block-group.h
fs/btrfs/free-space-tree.c
fs/btrfs/free-space-tree.h
fs/btrfs/relocation.c
fs/btrfs/relocation.h
fs/btrfs/space-info.c
fs/btrfs/volumes.c