diff options
| author | Qu Wenruo <wqu@suse.com> | 2026-05-22 18:53:53 +0930 |
|---|---|---|
| committer | David Sterba <dsterba@suse.com> | 2026-08-07 19:17:17 +0200 |
| commit | 49ba3a3c0d67aa74618a3f8dabea2e2e372102aa (patch) | |
| tree | 619b174d033a578361a8b65b964aebc5f45f7ad7 /tools/perf/scripts/python | |
| parent | 211362e627e12d8b7219aada034f7e7e6a558794 (diff) | |
btrfs: disguise single-data-RAID56 as RAID1/RAID1C3
Recently kernel RAID56 lib is trying to remove the unexpected
single-data-RAID56 (2 disks RAID5 or 3 disk RAID5) support, meanwhile
btrfs still supports such setup, which means in the long run btrfs has
to handle such corner case by ourselves.
Thankfully single-data-RAID56 is really RAID1/RAID1C3, since data and
P/Q stripes all match each other, rotation also makes no difference.
This patch will disguise those single-data-RAID56 chunks as
RAID1/RAID1C3 chunks.
This is done at two timings:
- Chunk read
- Chunk allocation
This is done by introducing btrfs_chunk_map::on_disk_type member, which
stores the type read from the on-disk metadata.
Meanwhile btrfs_chunk_map::type is calculated using on_disk_type.
For most profiles @type matches @on_disk_type, but for
single-data-RAID56, the @type will be RAID1/RAID1C3.
This method has a minimal impact on the fs, all other operations like
scrub and read-repair, are all based on the chunk map type, so the
disguise method will require no extra modification to those call sites.
Although there are still some locations that are checking against
block_group->flags, e.g. scrub. Those call sites will still get extra
limits assuming the bg is RAID56. But it should not cause any extra
problem.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
