[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a5d6d417-7050-9e42-4e20-59c8c893bab6@huaweicloud.com>
Date: Thu, 5 Feb 2026 20:57:39 +0800
From: Li Nan <linan666@...weicloud.com>
To: yukuai@...as.com, linan666@...weicloud.com, song@...nel.org
Cc: xni@...hat.com, linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org,
yangerkun@...wei.com, yi.zhang@...wei.com
Subject: Re: [PATCH v2 00/14] folio support for sync I/O in RAID
在 2026/2/5 1:02, Yu Kuai 写道:
> Hi,
>
> 在 2026/1/28 15:56, linan666@...weicloud.com 写道:
>> From: Li Nan <linan122@...wei.com>
>>
>> This patchset adds folio support to sync operations in raid1/10.
>> Previously, we used 16 * 4K pages for 64K sync I/O. With this change,
>> we'll use a single 64K folio instead. Using folios reduces
>> resync/recovery time by 20% on HDD.
>>
>> This is the first step towards full folio support in RAID. Going forward,
>> I will replace the remaining page-based usage with folio.
>>
>> The patchset was tested with mdadm. Additional fault injection stress tests
>> were run under file systems.
>
> For conclusion, I think you can send patch 1,8,9 first, they're not quite
Hi, kuai
Thanks for your review.
In handle_reshape_read_error(), if fix error in lbs before folio, we need
to consider 'idx' of page and offset in page, which make logical become
complex. I prefer making the change after folio , how do you think?
> related to folio and can be applied. Then, please move patch 12,13 before patch 5
Patches 12,13 only make sense after folio support. Cleanup before folio
offers little benefit. I will merge them directly into patch 5.
> in the separate patch set, and looks like the number of patches can be small.
>
> BTW, there are still pages in other context, do you plan to convert them?
>
Yes, there are still many page usages in bitmap and RAID5. I will continue
folio support work with this series as a reference after it is applied.
--
Thanks,
Nan
Powered by blists - more mailing lists