From: Mark Harmstone <mark@harmstone.com>
To: linux-btrfs@vger.kernel.org
Cc: Mark Harmstone <mark@harmstone.com>
Subject: [PATCH v2 00/16] btrfs: remap tree
Date: Wed, 13 Aug 2025 15:34:42 +0100 [thread overview]
Message-ID: <20250813143509.31073-1-mark@harmstone.com> (raw)
This patch series adds a disk format change gated behind
CONFIG_BTRFS_EXPERIMENTAL to add a "remap tree", which acts as a layer of
indirection when doing I/O. When doing relocation, rather than fixing up every
tree, we instead record the old and new addresses in the remap tree. This should
hopefully make things more reliable and flexible, as well as enabling some
future changes we'd like to make, such as larger data extents and reducing
write amplification by removing cow-only metadata items.
The remap tree lives in a new REMAP chunk type. This is because bootstrapping
means that it can't be remapped itself, and has to be relocated by COWing it as
at present. It can't go in the SYSTEM chunk as we are then limited by the chunk
item needing to fit in the superblock.
For more on the design and rationale, please see my RFC sent earlier this year[1], as
well as Josef Bacik's original design document[2]. The main change from Josef's
design is that I've added remap backrefs, as we need to be able to move a
chunk's existing remaps before remapping it.
You will also need my patches to btrfs-progs[3] to make
`mkfs.btrfs -O remap-tree` work, as well as allowing `btrfs check` to recognize
the new format.
Changelog:
Since v1:
* Fixed the problems with discard. Removing an extent in a remapped
block group now gets its address translated through the remap tree, and
when the last identity map of a block group is removed it triggers a
discard for its old dev extents
* Added relocation of the REMAP chunks, i.e. the chunks where the remap
tree itself lives. This can't be done by the existing method as we've
removed the metadata items in the extent tree, so we just COW every
leaf.
* Fixed a couple of lockdep issues
* Addressed the points that Boris made in his review
Since the RFC:
* I've reduce the REMAP chunk size from the normal 1GB to 32MB, to match the
SYSTEM chunk. For a filesystem with 4KB sectors and 16KB node size, the worst
case is that one leaf covers ~1MB of data, and the best case ~250GB. For a
chunk, that implies a worst case of ~2GB and a best case of ~500TB.
This isn't a disk-format change, so we can always adjust it if it proves too
big or small in practice. mkfs creates 8MB chunks, as it does for everything.
* You can't make new allocations from remapped block groups, so I've changed
it so there's no free-space entries for these (thanks to Boris Burkov for the
suggestion).
* The remap tree doesn't have metadata items in the extent tree (thanks to Josef
for the suggestion). This was to work around some corruption that delayed refs
were causing, but it also fits it with our future plans of removing all
metadata items for COW-only trees, reducing write amplification.
* btrfs_translate_remap() uses search_commit_root when doing metadata lookups,
to avoid nested locking issues. This also seems to be a lot quicker (btrfs/187
went from ~20mins to ~90secs).
* Unused remapped block groups should now get cleaned up more aggressively
* Other miscellaneous cleanups and fixes
Known issues:
* Some test failures: btrfs/156, btrfs/170, btrfs/226, btrfs/250
* nodatacow extents aren't safe, as they can race with the relocation thread.
We either need to follow the btrfs_inc_nocow_writers() approach, which COWs
the extent, or change it so that it blocks here.
* When initially marking a block group as remapped, we are walking the free-
space tree and creating the identity remaps all in one transaction. For the
worst-case scenario, i.e. a 1GB block group with every other sector allocated
(131,072 extents), this can result in transaction times of more than 10 mins.
This needs to be changed to allow this to happen over multiple transactions.
* All this is disabled for zoned devices for the time being, as I've not been
able to test it. I'm planning to make it compatible with zoned at a later
date.
Thanks
[1] https://lwn.net/Articles/1021452/
[2] https://github.com/btrfs/btrfs-todo/issues/54
[3] https://github.com/maharmstone/btrfs-progs/tree/remap-tree
Mark Harmstone (16):
btrfs: add definitions and constants for remap-tree
btrfs: add REMAP chunk type
btrfs: allow remapped chunks to have zero stripes
btrfs: remove remapped block groups from the free-space tree
btrfs: don't add metadata items for the remap tree to the extent tree
btrfs: add extended version of struct block_group_item
btrfs: allow mounting filesystems with remap-tree incompat flag
btrfs: redirect I/O for remapped block groups
btrfs: release BG lock before calling btrfs_link_bg_list()
btrfs: handle deletions from remapped block group
btrfs: handle setting up relocation of block group with remap-tree
btrfs: move existing remaps before relocating block group
btrfs: replace identity maps with actual remaps when doing relocations
btrfs: add do_remap param to btrfs_discard_extent()
btrfs: add fully_remapped_bgs list
btrfs: allow balancing remap tree
fs/btrfs/Kconfig | 2 +
fs/btrfs/accessors.h | 29 +
fs/btrfs/block-group.c | 233 +++-
fs/btrfs/block-group.h | 17 +-
fs/btrfs/block-rsv.c | 8 +
fs/btrfs/block-rsv.h | 1 +
fs/btrfs/discard.c | 11 +-
fs/btrfs/disk-io.c | 91 +-
fs/btrfs/extent-tree.c | 115 +-
fs/btrfs/extent-tree.h | 2 +-
fs/btrfs/free-space-cache.c | 2 +-
fs/btrfs/free-space-tree.c | 4 +-
fs/btrfs/free-space-tree.h | 5 +-
fs/btrfs/fs.h | 7 +-
fs/btrfs/inode.c | 2 +-
fs/btrfs/locking.c | 1 +
fs/btrfs/relocation.c | 1906 ++++++++++++++++++++++++++++++-
fs/btrfs/relocation.h | 7 +-
fs/btrfs/space-info.c | 22 +-
fs/btrfs/sysfs.c | 4 +
fs/btrfs/transaction.c | 8 +
fs/btrfs/transaction.h | 1 +
fs/btrfs/tree-checker.c | 92 +-
fs/btrfs/tree-checker.h | 5 +
fs/btrfs/volumes.c | 299 ++++-
fs/btrfs/volumes.h | 19 +-
include/uapi/linux/btrfs.h | 1 +
include/uapi/linux/btrfs_tree.h | 29 +-
28 files changed, 2717 insertions(+), 206 deletions(-)
--
2.49.1
next reply other threads:[~2025-08-13 14:35 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 14:34 Mark Harmstone [this message]
2025-08-13 14:34 ` [PATCH v2 01/16] btrfs: add definitions and constants for remap-tree Mark Harmstone
2025-08-15 23:51 ` Boris Burkov
2025-08-18 17:21 ` Mark Harmstone
2025-08-18 17:33 ` Boris Burkov
2025-08-16 0:01 ` Qu Wenruo
2025-08-16 0:17 ` Qu Wenruo
2025-08-18 17:23 ` Mark Harmstone
2025-08-13 14:34 ` [PATCH v2 02/16] btrfs: add REMAP chunk type Mark Harmstone
2025-08-13 14:34 ` [PATCH v2 03/16] btrfs: allow remapped chunks to have zero stripes Mark Harmstone
2025-08-16 0:03 ` Boris Burkov
2025-08-22 17:01 ` Mark Harmstone
2025-08-19 1:05 ` kernel test robot
2025-08-22 17:07 ` Mark Harmstone
2025-08-13 14:34 ` [PATCH v2 04/16] btrfs: remove remapped block groups from the free-space tree Mark Harmstone
2025-08-13 14:34 ` [PATCH v2 05/16] btrfs: don't add metadata items for the remap tree to the extent tree Mark Harmstone
2025-08-16 0:06 ` Boris Burkov
2025-08-13 14:34 ` [PATCH v2 06/16] btrfs: add extended version of struct block_group_item Mark Harmstone
2025-08-16 0:08 ` Boris Burkov
2025-08-13 14:34 ` [PATCH v2 07/16] btrfs: allow mounting filesystems with remap-tree incompat flag Mark Harmstone
2025-08-22 19:14 ` Boris Burkov
2025-08-13 14:34 ` [PATCH v2 08/16] btrfs: redirect I/O for remapped block groups Mark Harmstone
2025-08-22 19:42 ` Boris Burkov
2025-08-27 14:08 ` Mark Harmstone
2025-08-13 14:34 ` [PATCH v2 09/16] btrfs: release BG lock before calling btrfs_link_bg_list() Mark Harmstone
2025-08-16 0:32 ` Boris Burkov
2025-08-27 15:35 ` Mark Harmstone
2025-08-27 15:48 ` Filipe Manana
2025-08-27 15:52 ` Mark Harmstone
2025-08-13 14:34 ` [PATCH v2 10/16] btrfs: handle deletions from remapped block group Mark Harmstone
2025-08-16 0:28 ` Boris Burkov
2025-08-27 17:11 ` Mark Harmstone
2025-08-13 14:34 ` [PATCH v2 11/16] btrfs: handle setting up relocation of block group with remap-tree Mark Harmstone
2025-08-13 14:34 ` [PATCH v2 12/16] btrfs: move existing remaps before relocating block group Mark Harmstone
2025-08-13 14:34 ` [PATCH v2 13/16] btrfs: replace identity maps with actual remaps when doing relocations Mark Harmstone
2025-08-13 14:34 ` [PATCH v2 14/16] btrfs: add do_remap param to btrfs_discard_extent() Mark Harmstone
2025-08-13 14:34 ` [PATCH v2 15/16] btrfs: add fully_remapped_bgs list Mark Harmstone
2025-08-16 0:56 ` Boris Burkov
2025-08-27 18:51 ` Mark Harmstone
2025-08-13 14:34 ` [PATCH v2 16/16] btrfs: allow balancing remap tree Mark Harmstone
2025-08-16 1:02 ` Boris Burkov
2025-09-02 14:58 ` Mark Harmstone
2025-09-02 15:21 ` Mark Harmstone
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250813143509.31073-1-mark@harmstone.com \
--to=mark@harmstone.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.