From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/2] btrfs: introduce a new experimental feature, RAID56_VSL
Date: Thu, 3 Sep 2026 16:19:02 +0930 [thread overview]
Message-ID: <cover.1788417288.git.wqu@suse.com> (raw)
The new feature stands for RAID56 Variable Stripe Length, however the
VSL part is not implemented yet, thus the whole feature is still hidden
behind experimental, and there are definitely works left to properly
split the 1st patch.
But for now, this series can pass most fstests cases.
The failing ones are all related to mixed block groups, which can not be
created nor mounted with this new feature.
The roadmap for the full RAID56 VSL implementation is split into two
parts:
- Introduce a new datasize member
This series.
An fs with data_size 8K and sectorsize 4K will act like a fs with
sectorsize 8K.
Meaning the minimal write size is 8K for data.
However the checksum is still calculated based sectorsize, meanwhile
we can still recover each corrupted 4K sector inside a 8K data block.
The idea and implementation is not that complex, we're just reusing
the existing bs > ps support to handle it (on 4K page sized systems).
But the challenge is the details where some part of the code still
requires sectorsize (checksum related), meanwhile every other location
goes datasize for data.
- Introduce a new RAID56_VSL chunk type
It will have the following requirements:
* Can have up to (datasize / sectorsize) data stripes
* The number of data stripes are always power of 2
This is only for every RAID56_VSL chunk, users can still have
whatever number of devices in the fs.
* The full stripe length is always datasize
This allows every data write to be full stripe aligned.
And for read repair/scrub, we can still locate and recover a single
sector inside a RAID56 stripe.
This is less flex than the traditional RAID56, which has no limit on
the number of data stripes, but has the write-hole problem.
And will require users to determine the maximum device numbers at mkfs
time, without any way to change to another datasize.
But the second part is pretty easy to implement.
As the digest shows, the biggest problem is the first patch, which is
touching over 200 sectorsize users, and is definitely the source of all
bugs I hit and fixed so far.
If anyone has a better way to address the rename, I'm all ears.
Qu Wenruo (2):
btrfs: split sectorsize into datasize and sectorsize
btrfs: implement a new incompat feature, raid56_vsl
fs/btrfs/accessors.h | 2 +
fs/btrfs/bio.c | 16 +++-
fs/btrfs/block-group.c | 2 +-
fs/btrfs/btrfs_inode.h | 10 +++
fs/btrfs/compression.c | 12 +--
fs/btrfs/defrag.c | 14 +--
fs/btrfs/delalloc-space.c | 22 ++---
fs/btrfs/direct-io.c | 6 +-
fs/btrfs/disk-io.c | 43 +++++++---
fs/btrfs/extent-io-tree.c | 2 +-
fs/btrfs/extent-tree.c | 4 +-
fs/btrfs/extent_io.c | 62 +++++++-------
fs/btrfs/extent_map.c | 2 +-
fs/btrfs/fiemap.c | 2 +-
fs/btrfs/file-item.c | 22 +++--
fs/btrfs/file.c | 72 ++++++++--------
fs/btrfs/fs.h | 27 ++++--
fs/btrfs/inode-item.c | 6 +-
fs/btrfs/inode.c | 113 +++++++++++++------------
fs/btrfs/ioctl.c | 12 +--
fs/btrfs/lzo.c | 14 +--
fs/btrfs/reflink.c | 16 ++--
fs/btrfs/relocation.c | 16 ++--
fs/btrfs/send.c | 4 +-
fs/btrfs/subpage.c | 96 +++++++++++++++------
fs/btrfs/subpage.h | 2 +-
fs/btrfs/super.c | 8 +-
fs/btrfs/sysfs.c | 8 +-
fs/btrfs/tests/btrfs-tests.c | 6 +-
fs/btrfs/tests/free-space-tree-tests.c | 2 +-
fs/btrfs/tree-checker.c | 2 +-
fs/btrfs/tree-log.c | 6 +-
fs/btrfs/volumes.c | 2 +-
fs/btrfs/zlib.c | 6 +-
fs/btrfs/zoned.c | 4 +-
fs/btrfs/zstd.c | 8 +-
include/uapi/linux/btrfs.h | 22 +++++
include/uapi/linux/btrfs_tree.h | 3 +-
38 files changed, 403 insertions(+), 273 deletions(-)
--
2.55.0
next reply other threads:[~2026-09-03 6:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 6:49 Qu Wenruo [this message]
2026-09-03 6:49 ` [PATCH 1/2] btrfs: split sectorsize into datasize and sectorsize Qu Wenruo
2026-09-03 6:49 ` [PATCH 2/2] btrfs: implement a new incompat feature, raid56_vsl Qu Wenruo
2026-09-03 12:33 ` [PATCH 0/2] btrfs: introduce a new experimental feature, RAID56_VSL Johannes Thumshirn
2026-09-03 21:31 ` Qu Wenruo
2026-09-04 20:15 ` Goffredo Baroncelli
2026-09-04 21:43 ` Qu Wenruo
2026-09-05 13:51 ` Goffredo Baroncelli
2026-09-05 22:25 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1788417288.git.wqu@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.