diff options
author | Johannes Thumshirn <johannes.thumshirn@wdc.com> | 2024-10-23 16:25:17 +0300 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2024-11-11 16:34:19 +0300 |
commit | 6aea95ee318890d9add03b9275bde31fec682e80 (patch) | |
tree | 8fc11f478b29ac317a62ec0e69267c2124a78958 /tools/perf/scripts/python/export-to-sqlite.py | |
parent | d07eaa9995fc81eb18e390d860442e598427547d (diff) | |
download | linux-6aea95ee318890d9add03b9275bde31fec682e80.tar.xz |
btrfs: implement partial deletion of RAID stripe extents
In our CI system, the RAID stripe tree configuration sometimes fails with
the following ASSERT():
assertion failed: found_start >= start && found_end <= end, in fs/btrfs/raid-stripe-tree.c:64
This ASSERT()ion triggers, because for the initial design of RAID
stripe-tree, I had the "one ordered-extent equals one bio" rule of zoned
btrfs in mind.
But for a RAID stripe-tree based system, that is not hosted on a zoned
storage device, but on a regular device this rule doesn't apply.
So in case the range we want to delete starts in the middle of the
previous item, grab the item and "truncate" it's length. That is, clone
the item, subtract the deleted portion from the key's offset, delete the
old item and insert the new one.
In case the range to delete ends in the middle of an item, we have to
adjust both the item's key as well as the stripe extents and then
re-insert the modified clone into the tree after deleting the old stripe
extent.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-sqlite.py')
0 files changed, 0 insertions, 0 deletions