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.