| From: |
| Qu Wenruo <wqu-AT-suse.com> |
| To: |
| linux-btrfs-AT-vger.kernel.org |
| Subject: |
| [PATCH 0/3] btrfs: disguise single-data-RAID56 as RAID1/RAID1C3 |
| Date: |
| Fri, 22 May 2026 18:53:50 +0930 |
| Message-ID: |
| <cover.1779412152.git.wqu@suse.com> |
| Cc: |
| hch-AT-lst.de, linux-raid-AT-vger.kernel.org |
| Archive-link: |
| Article |
[CHANGELOG]
RFC->v1:
- Remove unused btrfs_chunk_map::io_(align|width) members
To make space for the new member.
- Fix a duplicated bg->flags assignment in fill_dummy_bgs()
Just exposed by the last patch which also touches that code.
- Use a dedicated member to record the on-disk chunk type
So it's less fragile than the RFC patch.
The single-data-RAID56 (2 disks raid5 or 3 disks raid6) is not a feature
that should be supported in the first place, thus raid56 is going to
remove such support.
Meanwhile rejecting single-data-RAID56 will cause existing btrfs users
unable to mount their fs, even if there is only a single
empty chunk with that flag, mostly caused by some degraded mount.
So to avoid impacting existing users, implement an internal
single-data-RAID56 to RAID1/RAID1C3 mapping, to co-operate with the
upstream raid56 lib changes.
Qu Wenruo (3):
btrfs: remove btrfs_chunk_map::io_(align|width) members
btrfs: remove duplicated block group type assignment
btrfs: disguise single-data-RAID56 as RAID1/RAID1C3
fs/btrfs/block-group.c | 3 +--
fs/btrfs/volumes.c | 25 ++++++++++++++++++-------
fs/btrfs/volumes.h | 10 ++++++++--
3 files changed, 27 insertions(+), 11 deletions(-)
--
2.54.0