]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
btrfs: don't add metadata items for the remap tree to the extent tree
authorMark Harmstone <mark@harmstone.com>
Wed, 7 Jan 2026 14:09:05 +0000 (14:09 +0000)
committerDavid Sterba <dsterba@suse.com>
Tue, 3 Feb 2026 06:54:34 +0000 (07:54 +0100)
commitefcab3176eb28427177c6319e128b41efd03ffdd
tree3182a27618c388ad678b5e3180a9ec701e915547
parent76377db18a8fb96511b09643e407fe3f9b0a9357
btrfs: don't add metadata items for the remap tree to the extent tree

There is the following potential problem with the remap tree and delayed refs:

* Remapped extent freed in a delayed ref, which removes an entry from the
  remap tree
* Remap tree now small enough to fit in a single leaf
* Corruption as we now have a level-0 block with a level-1 metadata item
  in the extent tree

One solution to this would be to rework the remap tree code so that it operates
via delayed refs. But as we're hoping to remove cow-only metadata items in the
future anyway, change things so that the remap tree doesn't have any entries in
the extent tree. This also has the benefit of reducing write amplification.

We also make it so that the clear_cache mount option is a no-op, as with the
extent tree v2, as the free-space tree can no longer be recreated from the
extent tree.

Finally disable relocating the remap tree itself, which is added back in
a later patch. As it is we would get corruption as the traditional
relocation method walks the extent tree, and we're removing its metadata
items.

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/disk-io.c
fs/btrfs/extent-tree.c
fs/btrfs/volumes.c