From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-1-17.ptr.blmpb.com (sg-1-17.ptr.blmpb.com [118.26.132.17]) (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 E030B34E77A for ; Thu, 6 Nov 2025 17:06:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.26.132.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762448782; cv=none; b=J4YrJJS+SJNsQZXTXMBI9OPECr/Q8ecGSl7Olf+GiZmPRnRhM0+MrY4MHcjqF+/Uv5FyMLPc10ckmY3WyYRqojIVg5eRHXMUCCp61xan9LCEFhm/OymeqmLzb+3ghJxzBULcB2GFJEkReeiEGjFoAmTikF3yQLYoRbM+kfgS1f4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762448782; c=relaxed/simple; bh=feCa6VUsW/nBHuedQ4gLtAXKsZ+WRYxs+1mOE0fpfTA=; h=Content-Type:To:From:Message-Id:In-Reply-To:Cc:Subject:References: Date:Mime-Version; b=YR8M3L+PChypQbyG8PVnz73LL3lxd5ivtv6DIHB6S7Lhdq54CJK5nSDxyJHQW0xVSSp37qS8mTj6vAP/Z9ef8Amht23Ci6XUifplU+N+BkEYOIFj70NGrhb2IYcxB6OcYDsh0EDwldqzUUw7XmE+28tmBI3FqFeGp87QWnD+7BY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fnnas.com; spf=none 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=36aWqGg5; arc=none smtp.client-ip=118.26.132.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fnnas.com Authentication-Results: smtp.subspace.kernel.org; spf=none 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="36aWqGg5" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=s1; d=fnnas-com.20200927.dkim.feishu.cn; t=1762448766; h=from:subject:mime-version:from:date:message-id:subject:to:cc: reply-to:content-type:mime-version:in-reply-to:message-id; bh=feCa6VUsW/nBHuedQ4gLtAXKsZ+WRYxs+1mOE0fpfTA=; b=36aWqGg5Lk9MGTKi1dGVYeuoXujOQ4vq1wVS4PK0YnHejD4nn8u3/kna0bBba/Ut1Rhxbp xkc9QJZVwk+ihiepJ916GPCNGVp/+JkMNVn6YjBCsFYRfawSjz73/ZFd2XJS7vOZzfY/y+ EjqOGsqe7ISA+VR98fkkBTrfOcSLPWUL5z/IcVr6mGpmKlaz+a4pAGXB3M6lleEAs2vcCt WuufI0n+TmuPa54U2/WjeAjb8QK7cjwgr393cLAwWr2mFQY8dwAWfTK3YforCVeKt2Bbha Bi+pG5VLCkgZ1W8T1exhDOk1/qFi1Uvxi4fiQyPzKphR2aaUuX/s/xTnTDjSbg== Content-Type: text/plain; charset=UTF-8 User-Agent: Mozilla Thunderbird Reply-To: yukuai@fnnas.com X-Lms-Return-Path: Content-Transfer-Encoding: quoted-printable Received: from [192.168.1.104] ([39.182.0.168]) by smtp.feishu.cn with ESMTPS; Fri, 07 Nov 2025 01:06:03 +0800 To: "Xiao Ni" From: "Yu Kuai" Message-Id: <8e240c3c-3cf7-4d48-8e13-2146a5d36c2b@fnnas.com> In-Reply-To: Cc: "Li Nan" , , , , , , , , Subject: Re: [PATCH v9 4/5] md: add check_new_feature module parameter References: <20251103125757.1405796-1-linan666@huaweicloud.com> <20251103125757.1405796-5-linan666@huaweicloud.com> <2c1ab8fc-99ac-44fd-892c-2eeedb9581f4@fnnas.com> <5396ce6f-ba67-4f5e-86dc-3c9aebb6dc20@fnnas.com> X-Original-From: Yu Kuai Date: Fri, 7 Nov 2025 01:06:02 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Hi, =E5=9C=A8 2025/11/6 22:56, Xiao Ni =E5=86=99=E9=81=93: > On Thu, Nov 6, 2025 at 9:31=E2=80=AFPM Yu Kuai wrote: >> Hi, >> >> =E5=9C=A8 2025/11/6 21:15, Xiao Ni =E5=86=99=E9=81=93: >>> In patch05, the commit says this: >>> >>> Future mdadm should support setting LBS via metadata field during RAID >>> creation and the new sysfs. Though the kernel allows runtime LBS change= s, >>> users should avoid modifying it after creating partitions or filesystem= s >>> to prevent compatibility issues. >>> >>> So it only can specify logical block size when creating an array. In >>> the case you mentioned above, in step3, the array will be assembled in >>> new kernel and the sb->pad3 will not be set, right? >> No, lbs will be set to the value array actually use in metadata, otherwi= se >> data loss problem will not be fixed for the array with different lbs fro= m >> underlying disks, this is what we want to fix in the first place. > But the case you mentioned is to assemble an existing array in a new > kernel. The existing array in the old kernel doesn't set lbs. So the > sb->pad3 will be zero when assembling it in the new kernel. Looks like you misunderstood the patch, lbs in sb->pad3 will be updated to = the real lbs when array is assembled in the new kernel. Set lbs in metadata is necessary to avoid data loss. And please noted this patch is required to be backported to old kernel to make it possible that array with default lbs can be assembled again in old kernel. > > And as planned, we will not support --lbs (for example) for the `mdadm > --assemble` command. > > The original problem should be fixed by specifying lbs when creating > an array (https://www.spinics.net/lists/raid/msg80870.html). Maybe we > should avoid updating lbs when adding a new disk=EF=BC=9F I don't understand, lbs modification should be forbidden once array is created, it's only allowed to be updated before the array is running the first time. > > Regards > Xiao >> Thanks, >> Kuai >>