Re: [PATCH RFC] btrfs: implement a new compat RO feature, data_io_size

"Sun YangKai" <[email protected]> Sat, 1 Aug 2026 09:02:29 +0800
Newsgroups org.kernel.vger.linux-btrfs
Message-ID <[email protected]>
On 2026/8/1 05:25, Qu Wenruo wrote:
>=20
>=20
> =E5=9C=A8 2026/7/31 21:10, Sun YangKai =E5=86=99=E9=81=93:
>> On 2026/7/22 18:03, Qu Wenruo wrote:
>>>
>>> Full stripe 16K, then the new RAID5F chunks will require power-of-2
>>> disks, and no more than 16K/4K disks.
>>>
>>> So no 4 disks RAID5F chunk in the first place.
>>
>> I've got your idea and got the following 2 concerns:
>>
>> 1. the device count is limited to 3 or 5 device for RAID5, and 4 or 6
>> devices for RAID6, losing the flexibility currently btrfs have;
>=20
> Why you think 16K is the only block size?

My bad.

> You can go as large as 64K, which means 16 data devices which is more=20
> than enough for common usages.

Makes a lot of sense.


> In fact, I do not think you should have overly flex design, which is=20
> contributing to the write-hole in the first place.

Write hole is directly caused by RMW partial stripe write, which we want=20
to get rid of.

>>
>> 2. On each device, we will send a lot of 4KiB or 8KiB io, which might be
>> not good for performance;
>=20
> It can always be solved usings blk plugs.

That makes sense. AFAIK, larger stripes is usually good for performance.=20
But maybe I missed the performance win brought by no partial stripe=20
write. If benchmark shows a good result, this is not an issue.

Thanks a lot for your reply.

>>
>> So I personally don't think this is a good way to fix the write hole=20
>> issue.
>=20
> I do not think so.
>=20
> As I have already said, at least I know XFS is planning doing something=
=20
> similar. Although not to solve write-hole.