kernel/git/stable/linux.git/fs/btrfs/volumes.h, branch master

btrfs: remove the dev stats item for replace target device

2026-06-09T16:22:44+00:00

[MINOR PROBLEM] When a running dev-replace hits some error for the target device (devid 0), there will be a DEV_STATS with error records created at the next transaction commit. Unfortunately that item will never to be deleted. This means at the next dev-replace, if the replace is interrupted, then at the next mount, the target device will suddenly inherit the old error records from that DEV_STATS item, which can give some false alerts on that device. This shouldn't affect end users that much, as it requires all the following conditions to be met, which is pretty rare: - The initial dev-replace hits some error on the target device E.g. write errors, but those errors itself is already a big problem for a running replace. This is required to create the DEV_STATS item in the first place. - The next replace is interrupted This is required to allow btrfs to read from the old records. [CAUSE] Btrfs just never deletes the DEV_STATS after a replace is finished. [FIX] Remove the DEV_STATS item for devid 0 after the replace is finished. This is not going to completely fix the error, as we still have other error paths, e.g. by somehow the fs flips RO and can not start a new transaction for the DEV_STATS item removal. But those corner cases will be addressed by later patches which provide a more generic fix to DEV_STATS related problems. Signed-off-by: Qu Wenruo Signed-off-by: David Sterba

btrfs: limit size of bios submitted from writeback

2026-06-08T13:53:30+00:00

Currently btrfs_writepages() just accumulates as large bio as possible (within writeback_control constraints) and then submits it. This can however lead to significant latency in writeback IO submission (I have observed tens of milliseconds) because the submitted bio easily has over hundred of megabytes. Consequently this leads to IO pipeline stalls and reduced throughput. At the same time beyond certain size submitting so large bio provides diminishing returns because the bio is split by the block layer immediately anyway. So compute (estimate of) bio size beyond which we are unlikely to improve performance and just submit the bio for writeback once we accumulate that much to keep the IO pipeline busy. This improves writeback throughput for sequential writes by about 15% on the test machine I was using. Reviewed-by: Qu Wenruo Signed-off-by: Jan Kara [ Fix the handling of missing device to avoid NULL pointer dereference. ] Signed-off-by: Qu Wenruo Signed-off-by: David Sterba

btrfs: introduce the device layout aware per-profile available space

2026-04-07T16:55:53+00:00

[BUG] There is a long known bug that if metadata is using RAID1 on two disks with unbalanced sizes, there is a very high chance to hit ENOSPC related transaction abort. [CAUSE] The root cause is in the available space estimation code: - Factor based calculation Just use all unallocated space, divide by the profile factor One obvious user is can_overcommit(). This can not handle the following example: devid 1 unallocated: 1GiB devid 2 unallocated: 50GiB metadata type: RAID1 If using factor based estimation, we can use (1GiB + 50GiB) / 2 = 25.5GiB free space for metadata. Thus we can continue allocating metadata (over-commit) way beyond the 1GiB limit. But this estimation is completely wrong, in reality we can only allocate one single 1GiB RAID1 block group, thus if we continue over-commit, at one time we will hit ENOSPC at some critical path and flips the fs read-only. [SOLUTION] This patch will introduce per-profile available space estimation, which can provide chunk-allocator like behavior to give a (mostly) accurate result, with under-estimate corner cases. There are some differences between the estimation and real chunk allocator: - No consideration on hole size It's fine for most cases, as all data/metadata strips are in 1GiB size thus there should not be any hole wasting much space. And chunk allocator is able to use smaller stripes when there is really no other choice. Although in theory this means it can lead to some over-estimation, it should not cause too much hassle in the real world. The other benefit of such behavior is, we avoid dev-extent tree search completely, thus the overhead is very small. - No true balance for certain cases If we have 3 disks RAID1, and each device has 2GiB unallocated space, we can load balance the chunk allocation so that we can allocate 3GiB RAID1 chunks, and that's what chunk allocator will do. But this current estimation code is using the largest available space to do a single allocation. Meaning the estimation will be 2GiB, thus under estimate. Such under estimation is fine and after the first chunk allocation, the estimation will be updated and still give a correct 2GiB estimation. So this only means the estimation will be a little conservative, which is safer for call sites like metadata over-commit check. With that facility, for above 1GiB + 50GiB case, it will give a RAID1 estimation of 1GiB, instead of the incorrect 25.5GiB. Or for a more complex example: devid 1 unallocated: 1T devid 2 unallocated: 1T devid 3 unallocated: 10T We will get an array of: RAID10: 2T RAID1: 2T RAID1C3: 1T RAID1C4: 0 (not enough devices) DUP: 6T RAID0: 3T SINGLE: 12T RAID5: 2T RAID6: 1T [IMPLEMENTATION] And for the each profile , we go chunk allocator level calculation: The pseudo code looks like: clear_virtual_used_space_of_all_rw_devices(); do { /* * The same as chunk allocator, despite used space, * we also take virtual used space into consideration. */ sort_device_with_virtual_free_space(); /* * Unlike chunk allocator, we don't need to bother hole/stripe * size, so we use the smallest device to make sure we can * allocated as many stripes as regular chunk allocator */ stripe_size = device_with_smallest_free->avail_space; stripe_size = min(stripe_size, to_alloc / ndevs); /* * Allocate a virtual chunk, allocated virtual chunk will * increase virtual used space, allow next iteration to * properly emulate chunk allocator behavior. */ ret = alloc_virtual_chunk(stripe_size, &allocated_size); if (ret == 0) avail += allocated_size; } while (ret == 0) This minimal available space based calculation is not perfect, but the important part is, the estimation is never exceeding the real available space. This patch just introduces the infrastructure, no hooks are executed yet. Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba

btrfs: add cleanup function for btrfs_free_chunk_map

2026-02-03T06:59:06+00:00

Signed-off-by: Naohiro Aota Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: tests: add unit tests for pending extent walking functions

2026-02-03T06:56:25+00:00

I ran into another sort of trivial bug in v1 of the patch and concluded that these functions really ought to be unit tested. These two functions form the core of searching the chunk allocation pending extent bitmap and have relatively easily definable semantics, so unit testing them can help ensure the correctness of chunk allocation. I also made a minor unrelated fix in volumes.h to properly forward declare btrfs_space_info. Because of the order of the includes in the new test, this was actually hitting a latent build warning. Note: This is an early example for me of a commit authored in part by an AI agent, so I wanted to more clear about what I did. I defined a trivial test and explained the set of tests I wanted to the agent and it produced the large set of test cases seen here. I then checked each test case to make sure it matched the description and simplified the constants and numbers until they looked reasonable to me. I then checked the looping logic to make sure it made sense to the original spirit of the trivial test. Finally, carefully combed over all the lines it wrote to loop over the tests it generated to make sure they followed our code style guide. Assisted-by: Claude:claude-opus-4-5 Signed-off-by: Boris Burkov Signed-off-by: David Sterba

btrfs: add do_remap parameter to btrfs_discard_extent()

2026-02-03T06:54:35+00:00

btrfs_discard_extent() can be called either when an extent is removed or from walking the free-space tree. With a remapped block group these two things are no longer equivalent: the extent's addresses are remapped, while the free-space tree exclusively uses underlying addresses. Add a do_remap parameter to btrfs_discard_extent() and btrfs_map_discard(), saying whether or not the address needs to be run through the remap tree first. Reviewed-by: Boris Burkov Signed-off-by: Mark Harmstone Signed-off-by: David Sterba

btrfs: handle deletions from remapped block group

2026-02-03T06:54:35+00:00

Handle the case where we free an extent from a block group that has the REMAPPED flag set. Because the remap tree is orthogonal to the extent tree, for data this may be within any number of identity remaps or actual remaps. If we're freeing a metadata node, this will be wholly inside one or the other. btrfs_remove_extent_from_remap_tree() searches the remap tree for the remaps that cover the range in question, then calls remove_range_from_remap_tree() for each one, to punch a hole in the remap and adjust the free-space tree. For an identity remap, remove_range_from_remap_tree() will adjust the block group's `identity_remap_count` if this changes. If it reaches zero we mark the block group as fully remapped. For an identity remap, remove_range_from_remap_tree() will adjust the block group's `identity_remap_count` if this changes. If it reaches zero we mark the block group as fully remapped. Fully remapped block groups have their chunk stripes removed and their device extents freed, which makes the disk space available again to the chunk allocator. This happens asynchronously: in the cleaner thread for sync discard and nodiscard, and (in a later patch) in the discard worker for async discard. Reviewed-by: Boris Burkov Signed-off-by: Mark Harmstone Signed-off-by: David Sterba

btrfs: add METADATA_REMAP chunk type

2026-02-03T06:54:27+00:00

Add a new METADATA_REMAP chunk type, which is a metadata chunk that holds the remap tree. This is needed for bootstrapping purposes: the remap tree can't itself be remapped, and must be relocated the existing way, by COWing every leaf. The remap tree can't go in the SYSTEM chunk as space there is limited, because a copy of the chunk item gets placed in the superblock. The changes in fs/btrfs/volumes.h are because we're adding a new block group type bit after the profile bits, and so can no longer rely on the const_ilog2 trick. The sizing to 32MB per chunk, matching the SYSTEM chunk, is an estimate here, we can adjust it later if it proves to be too big or too small. This works out to be ~500,000 remap items, which for a 4KB block size covers ~2GB of remapped data in the worst case and ~500TB in the best case. Reviewed-by: Boris Burkov Signed-off-by: Mark Harmstone Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: shrink the size of btrfs_device

2026-02-03T06:51:43+00:00

There are two main causes of holes inside btrfs_device: - The single bytes member of last_flush_error Not only it's a single byte member, but we never really care about the exact error number. - The @devt member Which is placed between two u64 members. Shrink the size of btrfs_device by: - Use a single bit flag for flush error Use BTRFS_DEV_STATE_FLUSH_FAILED so that we no longer need that dedicated member. - Move @devt to the hole after dev_stat_values[] This reduces the size of btrfs_device from 528 to exact 512 bytes for x86_64. Reviewed-by: Boris Burkov Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: remove experimental offload csum mode

2026-02-03T06:51:43+00:00

The offload csum mode was introduced to allow developers to compare the performance of generating checksum for data writes at different timings: - During btrfs_submit_chunk() This is the most common one, if any of the following condition is met we go this path: * The csum is fast For now it's CRC32C and xxhash. * It's a synchronous write * Zoned - Delay the checksum generation to a workqueue However since commit dd57c78aec39 ("btrfs: introduce btrfs_bio::async_csum") we no longer need to bother any of them. As if it's an experimental build, async checksum generation at the background will be faster anyway. And if not an experimental build, we won't even have the offload csum mode support. Considering the async csum will be the new default, let's remove the offload csum mode code. There will be no impact to end users, and offload csum mode is still under experimental features. Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba