Re: [PATCH] btrfs: tag all metadata I/O with REQ_META

[Марк Коренберг]

On Wed, Nov 04, 2026 at 06:21:40PM +0100, David Sterba wrote:
> Remap tree is experimental feature in btrfs-progs, so you'd have to do
> custom build with './configure --enable-experimental', then
> 'mkfs.btrfs -O list-all' will contain 'remapt-ree'.

Thanks, that worked.  I tested the remap part now: btrfs-progs devel
(4f5956a) with --enable-experimental, kernel with
CONFIG_BTRFS_EXPERIMENTAL, a 2 GiB filesystem with remap-tree, DUP
metadata and single data, /usr/include copied in, then "balance -m"
twice and "balance -d" twice.  kprobes on entry and return of
copy_remapped_data_io() mark the bios of each copy.

Both callers of copy_remapped_data() are covered: the first balance
goes through do_remap_reloc_trans(), the second one mostly through
move_existing_remap().

Copy bios, with REQ_META / without:

                      without the patch     with the patch
                      run 1      run 2
  metadata, reads     0 / 56     0 / 74        70 / 0
  metadata, writes    0 / 112    0 / 148      140 / 0
  data, reads         0 / 288    0 / 288        0 / 288
  data, writes        0 / 288    0 / 288        0 / 288

The metadata counts vary from run to run on the same kernel: each
contiguous range of the block group is copied separately, and how
fragmented the metadata ends up after the copy depends on the timing
of the commits.  Writes are twice the reads because of DUP.

btrfs check finds no errors afterwards, no warnings in the log.

One thing on the way: mkfs.btrfs from devel crashes with any
"-O remap-tree".  create_metadata_block_groups() commits a
transaction before setup_remap_tree_root() has created the tree, and
write_ctree_super() then dereferences fs_info->remap_root->node, which
is still NULL.  For the test I skipped the remap root fields in
write_ctree_super() while the node is not there yet.