diff options
author | Naohiro Aota <naohiro.aota@wdc.com> | 2025-06-29 23:07:42 +0900 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2025-07-22 00:09:23 +0200 |
commit | 3061801420469610c8fa6080a950e56770773ef1 (patch) | |
tree | defc561d38a6fdb0e9afefe5b7cf959c278d69e7 /lib/xarray.c | |
parent | d6be378de06c8ae72c46d528f69cc53fa382b01c (diff) |
btrfs: zoned: do not remove unwritten non-data block group
There are some reports of "unable to find chunk map for logical 2147483648
length 16384" error message appears in dmesg. This means some IOs are
occurring after a block group is removed.
When a metadata tree node is cleaned on a zoned setup, we keep that node
still dirty and write it out not to create a write hole. However, this can
make a block group's used bytes == 0 while there is a dirty region left.
Such an unused block group is moved into the unused_bg list and processed
for removal. When the removal succeeds, the block group is removed from the
transaction->dirty_bgs list, so the unused dirty nodes in the block group
are not sent at the transaction commit time. It will be written at some
later time e.g, sync or umount, and causes "unable to find chunk map"
errors.
This can happen relatively easy on SMR whose zone size is 256MB. However,
calling do_zone_finish() on such block group returns -EAGAIN and keep that
block group intact, which is why the issue is hidden until now.
Fixes: afba2bc036b0 ("btrfs: zoned: implement active zone tracking")
CC: stable@vger.kernel.org # 6.1+
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'lib/xarray.c')
0 files changed, 0 insertions, 0 deletions