From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-1-38.ptr.blmpb.com (sg-1-38.ptr.blmpb.com [118.26.132.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B435019CD0A for ; Wed, 4 Mar 2026 02:38:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.26.132.38 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772591903; cv=none; b=AURTBFOjaj7Pp6v4MJwi7dl9EZuCkFrOqdE0nYhaiU1JQ1en4TQ3vyCW2MF+9dDgiMPrgg6sFrEmfvTbK27eneYnRg+mzmwKxpSmvr1AoMr2NkqpfzukKyvfexf9GYp+TRXQrKDItLjrnBbm8cOd90roJo0CtDt1+TfmEYDq9Vk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772591903; c=relaxed/simple; bh=wjice0ZpfdZEj3p6iNIPqvVKspu3pO8tVFgbPLPfulQ=; h=From:Message-Id:In-Reply-To:To:Mime-Version:Content-Type:Subject: Date:References:Cc; b=uIxgG5mSmVblYk+qB+/3n+dmu8CPg3kFudGmt/B97C0wV9fkpdHEeRAQB+4mM6NRq/8ASFaNffPUK+68KbhTJV1pK8xC/ozR1HkMsJXhfK/BBQw0ogDTQc3HUeGtY4nfw869BJesM5P2Ue+6vk7P4ePnOOPjxm2lJDJRY4lQ6fI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fnnas.com; spf=pass smtp.mailfrom=fnnas.com; dkim=pass (2048-bit key) header.d=fnnas-com.20200927.dkim.feishu.cn header.i=@fnnas-com.20200927.dkim.feishu.cn header.b=f1CnaAG7; arc=none smtp.client-ip=118.26.132.38 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fnnas.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fnnas.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fnnas-com.20200927.dkim.feishu.cn header.i=@fnnas-com.20200927.dkim.feishu.cn header.b="f1CnaAG7" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=s1; d=fnnas-com.20200927.dkim.feishu.cn; t=1772591782; h=from:subject:mime-version:from:date:message-id:subject:to:cc: reply-to:content-type:mime-version:in-reply-to:message-id; bh=wjice0ZpfdZEj3p6iNIPqvVKspu3pO8tVFgbPLPfulQ=; b=f1CnaAG7VgpVpFlJlZgZczZ6LEjeTS6znON1HuLVfTiu8bJvNJJxybIdmrU0veXB8ezaPs WEA3gjntWMVvi2fZPxiCgGO+Ri5HqohwxZtdfgCUG8BpfIJiIfPh+hKB3/vKvDYcHgf6OU 68kbV9e97urjouHEtRKEdSX/dTlglf9/eLWvsYS3YVsHy9I2NYQ8iCX8qXHREGM+QdHyFc u/0DwNSrh2JAIGW4sYjSvJC5VLRu34/LvfSB7cTyPWyM1uAf9SC+KsK0BEhWln1s2uYS3p digASqFeutL8HGcRoq/8eC0P7ybkunowEInUK/Uc3pUHv7Mh5Bd3HZ1cDwfY9w== X-Original-From: Yu Kuai From: "Yu Kuai" Message-Id: <18c49c55-bc45-4ffd-83cb-4884ac024b54@fnnas.com> Content-Transfer-Encoding: quoted-printable In-Reply-To: To: "Paul Menzel" , Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Lms-Return-Path: Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH] md/raid5: set chunk_sectors to enable full stripe I/O splitting User-Agent: Mozilla Thunderbird Date: Wed, 4 Mar 2026 10:36:17 +0800 Content-Language: en-US Received: from [192.168.1.104] ([39.182.0.182]) by smtp.feishu.cn with ESMTPS; Wed, 04 Mar 2026 10:36:18 +0800 References: <20260223035834.3132498-1-yukuai@fnnas.com> Reply-To: yukuai@fnnas.com Cc: , , , , Hi, =E5=9C=A8 2026/2/23 15:26, Paul Menzel =E5=86=99=E9=81=93: > Dear Kuai, > > > Thank you for your patch. > > Am 23.02.26 um 04:58 schrieb Yu Kuai: >> Set chunk_sectors to the full stripe width (io_opt) so that the block >> layer splits I/O at full stripe boundaries. This ensures that large >> writes are aligned to full stripes, avoiding the read-modify-write >> overhead that occurs with partial stripe writes in RAID-5/6. >> >> When chunk_sectors is set, the block layer's bio splitting logic in >> get_max_io_size() uses blk_boundary_sectors_left() to limit I/O size >> to the boundary. This naturally aligns split bios to full stripe >> boundaries, enabling more efficient full stripe writes. >> >> Test results with 24-disk RAID5 (chunk_size=3D64k): >> =C2=A0=C2=A0 dd if=3D/dev/zero of=3D/dev/md0 bs=3D10M oflag=3Ddirect >> =C2=A0=C2=A0 Before: 461 MB/s >> =C2=A0=C2=A0 After:=C2=A0 520 MB/s=C2=A0 (+12.8%) > > Sweet. > >> Suggested-by: Christoph Hellwig >> Signed-off-by: Yu Kuai > > Once committed, should this be backported to the longterm and stable=20 > series? Sorry for the delay, this is just performance improvement, I think this wil= l not be backported automatically.This patch need to be send to LTS with some explanation if someone is interested. > >> --- >> =C2=A0 drivers/md/raid5.c | 1 + >> =C2=A0 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c >> index 8854e024f311..810d936560d1 100644 >> --- a/drivers/md/raid5.c >> +++ b/drivers/md/raid5.c >> @@ -7783,6 +7783,7 @@ static int raid5_set_limits(struct mddev *mddev) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lim.logical_block_size =3D mddev->logical= _block_size; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lim.io_min =3D mddev->chunk_sectors << 9; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lim.io_opt =3D lim.io_min * (conf->raid_d= isks - conf->max_degraded); >> +=C2=A0=C2=A0=C2=A0 lim.chunk_sectors =3D lim.io_opt >> 9; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lim.features |=3D BLK_FEAT_RAID_PARTIAL_S= TRIPES_EXPENSIVE; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lim.discard_granularity =3D stripe; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lim.max_write_zeroes_sectors =3D 0; > > Reviewed-by: Paul Menzel > > > Kind regards, > > Paul > --=20 Thansk, Kuai