diff options
| author | Boris Burkov <boris@bur.io> | 2026-09-28 17:20:34 -0700 |
|---|---|---|
| committer | David Sterba <dsterba@suse.com> | 2026-10-12 19:16:23 +0200 |
| commit | 5612507486cdbd6da23b5bb972a8fcc192570d15 (patch) | |
| tree | bd29ec62ca9d4c576ab1140eb13dd69d1cfa28c0 /tools/perf/scripts/python | |
| parent | cd5e2d2f2ea2b2c644ac8a01b50a8f22bd23610f (diff) | |
| download | linux-5612507486cdbd6da23b5bb972a8fcc192570d15.tar.gz linux-5612507486cdbd6da23b5bb972a8fcc192570d15.zip | |
btrfs: commit after deleting an unused block group if system space is low
If the device is fully allocated and the system space_info has no room
for a second copy of the chunk tree, deleting many unused block groups
in one transaction aborts it with -ENOSPC in btrfs_remove_chunk(). While
we can get ahead of this problem in practice by allocating the system
space more aggressively, that doesn't help a system that already got
into this state anyway. In particular, this would be a problem on
systems that got into this state on old code from before that
improvement, but it is also a backstop in case we do mess up and still
end up with too little system space.
The way we end up needing a lot of system chunk space in practice is if
we need to delete many bgs at once, resulting in touching many
nodes/leaves in the chunk tree. Therefore, if we detect we are in a
condition where we are low on system space, commit a single transaction
deleting a single bg, which should not need much system chunk space.
After this we have the freed bg and can proceed as usual. Any additional
chunk allocations (for any reason) will also check the system space and
are very likely to allocate more system space, so this should be a
relatively robust mechanism.
Assisted-by: LLM
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
