From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (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 152313FE37A for ; Wed, 8 Jul 2026 09:05:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783501533; cv=none; b=HgcCrlUc8UyzWnUHj9fkXRXBi2yOrirWxfDJr22nUvGHXguJC/9ZiiIxssMYttBMab2qfwQhp+5UHCz8F04zuAX+QI6AjUL3R4zhzHtkwbgywV6PXtrMCWpSQvGVL2iWUtCzDZPtXvMd5vwOvYFDk6GIAx0dxmTaDEToByQNPCM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783501533; c=relaxed/simple; bh=wnsjc0TTT8++uRt/i+f+itVgjw2nO2+vbqNJksJq6Cs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=dIGw0MR/O6BRLUMWVWg4f7kX0DkWZTusW4/YhqeR+jH7OyBXE5DXP3ehz7WFgqqCH97nYXQrVjZlm+dOhE/lltUlbJss4oYMBABf8ZKQa7GC9QHH3C2C0/2QvSoCEwPCnx2hbxYBU3GNwyqcp+K/ifyEzKpR0FRbEqLX9B2duNc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dfojDrwJ; arc=none smtp.client-ip=209.85.128.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dfojDrwJ" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-493ba701891so3104235e9.3 for ; Wed, 08 Jul 2026 02:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783501530; x=1784106330; darn=vger.kernel.org; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ir0CO47nQT8KVIrdPQKQrEcLGdQC54RwQc/fSTsMcdQ=; b=dfojDrwJ+GnRkQb4q3iKeqesHu4oPoB41Hr7yprQ4iqAoeyzoWRvAWifsOnKF1xv57 n/atEf07jlEvyiG/ZqDeSlbmrUKd9sN5ANl5vk4BqiOujuT65pza2NEqGi8V/brBnkLb fGltIIkY8a/3kSWekxRJGtMj177VzpZDFmM0AkA62gk3Pc0huZSejOSMTUTyhyFxIDr0 CIfkhmYlntZKcdvwKJCyUg+7FsVXRo4sgPTx2AONWRY6OIM48l7hZiTZHyIHue9kJAb+ ZLDKL3eZCu4d4a8kE8EDAXE1ilmqPG2vd5HTC4a9TAODZ48RtyF02SGLG888W9q45VDh adxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783501530; x=1784106330; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=ir0CO47nQT8KVIrdPQKQrEcLGdQC54RwQc/fSTsMcdQ=; b=TqVfPc9gxIO/8XcFJdNXXKEgrEPrvdzdl4Qrw7iIR8xgos009RuqzZIhLLtrJvOqF/ nSQCUquWFTByUBFznbmxYOs2vrUwQApip1vGWl2QOmLIft+jIzpEiXGDIHVvchbBdDcL seMzeqv8AKoIR+Pwnmk5/O8WXjJWOy2PO29DoZgNwtzsrpFEg9V31znon9pyUZVDGSQn lfq1QW+oT5eIBAV+5CU+1xmkFcl78icXp3C8SXSCvffpzv3LH4vHaoRW+9RCMTPQHv4V yqTtsa8ycXUKUIneFZAQdxuSAKSIix8Ft2ZMgvoI0B2NgIK6+y7SrskcTQbiCoeVvd6E V6oA== X-Forwarded-Encrypted: i=1; AHgh+RrNhaIsaZH9nYVxeruwUhQy1xjflPTLLg2uotBTZuYNBBD8EgPGr5l+Io0eqEqOnB84OkNbGe66dOKUaIw=@vger.kernel.org X-Gm-Message-State: AOJu0YzbYw6ue9aJI/BNzhZr6nkbKBvUNBV8xAASuwSt/dL+9G4iMd3T q1bgU4JBf2Ce9rf2QzzDWioV3WZXdzUm9LKnsDZ5iF7ND5uBbBFgvkuD X-Gm-Gg: AfdE7cmcReUVuXimohaC5wdJFkcEocHI6SrgbsRxx79XnXVQzNr/jLNrIDaQmnDyiQT 0wT6ZBFdbkHgARmwHeOlgDWrSEuVDzVLJ3dQBlGOe5Aa1oY6vn9wqGhhpzqeoDjgTolkLJEY3EN JZMJXth8x4pHpK4PcuE3ZAr+53zXw1LK7rCzydIo9lkPEIHV2ZIKMyY0lX+1IYIUK12WsYSEEgf c386HabhCflNzFZuKcl4TTnsZUXJvAnsxSrp9AI6ATQVK1LfQ9U4h6oIgVr7x5mVrww3tf/VQgh G2LfG8rauy/Tko3loy1zFwUxNoDyN/+eM+Kt5bsb9R/Fke88kDtfkwHGL/y47Rs0fMXDllygcKS SiqxS3cFp1X0eGBHoaqmfgNVtsZOzgUKOlJoXvxeSgTYFFeMHR3UAzepXyeMPrrGslHAqLDWK4G qan0Ph1IDwdZm5ydfvof1xS+FUme2EoNlut/Soy8JiOX55JA== X-Received: by 2002:a05:600c:138c:b0:492:6447:7a7f with SMTP id 5b1f17b1804b1-493e688c6dbmr16518705e9.6.1783501530108; Wed, 08 Jul 2026 02:05:30 -0700 (PDT) Received: from Abds-MacBook-Air.local ([195.72.110.74]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47a9de1d8cdsm44254622f8f.1.2026.07.08.02.05.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 02:05:29 -0700 (PDT) From: Abd-Alrhman Masalkhi To: John Garry , song@kernel.org, yukuai@fygo.io, magiclinan@didiglobal.com, xiao@kernel.org, axboe@kernel.dk, vverma@digitalocean.com, martin.petersen@oracle.com, linux-kernel@vger.kernel.org Cc: linux-raid@vger.kernel.org Subject: Re: [PATCH v2 2/7] md/raid1: advertise atomic write limits and handle runtime constraints In-Reply-To: References: <20260628142420.1051027-1-abd.masalkhi@gmail.com> <20260628142420.1051027-3-abd.masalkhi@gmail.com> <7cbaaca3-4eb5-434d-a13f-f9574c9f977b@oracle.com> <856abedc-d2f3-4248-9583-4d7e1a11abc1@oracle.com> Date: Wed, 08 Jul 2026 11:05:28 +0200 Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Hi John, On Tue, Jul 07, 2026 at 17:20 +0100, John Garry wrote: > On 06/07/2026 12:35, Abd-Alrhman Masalkhi wrote: >>> well it seems to be that everything in the driver is split over >>> BARRIER_UNIT_SECTOR_SIZE, so is in effect a chunk size. >>> >>> Note that atomic_write_hw_unit_max is going to be small always compared >>> to BARRIER_UNIT_SECTOR_SIZE. >>> >>> However, can you check the blk stacking code to make sure that this does >>> as you want? As I remember, for stacking we take the atomic write limits >>> of the first bottom device and then stack the other bottom devices and I >>> don't think that setting atomic_write_hw_unit_max in this way has an >>> impact - see blk_stack_atomic_writes_limits() >>> >> I checked blk_stack_atomic_writes_limits(), and you are right: setting >> atomic_write_hw_unit_max here alone does not have the intended effect on >> the final stacked device. >> >> Also, since atomic_write_hw_unit_max is expected to always be smaller >> than BARRIER_UNIT_SECTOR_SIZE, > > Yes, always expected to be much smaller. > >> it seems that there is no need to set an >> additional atomic write limit in raid1, or even to set >> atomic_write_hw_unit_max at all. Is that what you mean? > > Even though we expect it to be much smaller, it's good practice to > ensure this. > > One method to do so - which I already mentioned - was to set the chunk > size to BARRIER_UNIT_SECTOR_SIZE. You were not keen on that. > I see, thanks for the clarification. My concern was mainly conceptual, and I was also worried that setting the chunk size might affect other operations, such as discard. Since that is not the case, I'll set the chunk size to BARRIER_UNIT_SECTOR_SIZE and update it accordingly in v2. > Another method is to set max hw sectors for the RAID1 device to > BARRIER_UNIT_SECTOR_SIZE. > > Thanks, > John > -- Best Regards, Abd-Alrhman