Skip to content

Commit d2c56f4

Browse files
naotakdave
authored andcommitted
btrfs: zoned: fixup last alloc pointer after extent removal for RAID1
When a block group is composed of a sequential write zone and a conventional zone, we recover the (pseudo) write pointer of the conventional zone using the end of the last allocated position. However, if the last extent in a block group is removed, the last extent position will be smaller than the other real write pointer position. Then, that will cause an error due to mismatch of the write pointers. We can fixup this case by moving the alloc_offset to the corresponding write pointer position. Fixes: 568220f ("btrfs: zoned: support RAID0/1/10 on top of raid stripe tree") CC: [email protected] # 6.12+ Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]>
1 parent 31f685e commit d2c56f4

File tree

1 file changed

+15
-0
lines changed

1 file changed

+15
-0
lines changed

fs/btrfs/zoned.c

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1491,6 +1491,21 @@ static int btrfs_load_block_group_raid1(struct btrfs_block_group *bg,
14911491
/* In case a device is missing we have a cap of 0, so don't use it. */
14921492
bg->zone_capacity = min_not_zero(zone_info[0].capacity, zone_info[1].capacity);
14931493

1494+
/*
1495+
* When the last extent is removed, last_alloc can be smaller than the other write
1496+
* pointer. In that case, last_alloc should be moved to the corresponding write
1497+
* pointer position.
1498+
*/
1499+
for (i = 0; i < map->num_stripes; i++) {
1500+
if (zone_info[i].alloc_offset == WP_MISSING_DEV ||
1501+
zone_info[i].alloc_offset == WP_CONVENTIONAL)
1502+
continue;
1503+
if (last_alloc <= zone_info[i].alloc_offset) {
1504+
last_alloc = zone_info[i].alloc_offset;
1505+
break;
1506+
}
1507+
}
1508+
14941509
for (i = 0; i < map->num_stripes; i++) {
14951510
if (zone_info[i].alloc_offset == WP_MISSING_DEV)
14961511
continue;

0 commit comments

Comments
 (0)