From: Nilay Shroff <nilay@linux.ibm.com>
To: Keith Busch <kbusch@kernel.org>, John Garry <john.g.garry@oracle.com>
Cc: axboe@kernel.dk, hch@lst.de, sagi@grimberg.me,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
tytso@mit.edu, martin.petersen@oracle.com, djwong@kernel.org,
mcgrof@infradead.org
Subject: Re: [RFC PATCH] nvme: add an opt-in to use AWUPF
Date: Thu, 21 Aug 2025 10:55:31 +0530 [thread overview]
Message-ID: <b8156bb1-b7fe-4036-9dbb-98fdcec3ff65@linux.ibm.com> (raw)
In-Reply-To: <aKZDRrfUTxJoFA1m@kbusch-mbp>
On 8/21/25 3:21 AM, Keith Busch wrote:
> On Wed, Aug 20, 2025 at 03:02:20PM +0000, John Garry wrote:
>> It would be preferred to stop honouring AWUPF altogether, but this may
>> needlessly disable atomic write support for many "good" devices which
>> only specify AWUPF. Currently all validation of controller-related
>> atomics limits is dropped.
>
> These "good" devices that only report AWUPF, is there some set of
> characteristics that generally applies to all of them?
Yes, I know of such “good” devices. Typically, they report a consistent
AWUPF value across all controllers, and that value does not change when
the namespaces attached to those controllers are reformatted.
As we know, though, validating this in code is difficult. A past attempt
to implement such validation failed because there are disks in the field
that do change the AWUPF value when reformatting namespaces.
> I tried to list out conditions for when I think the value could be counted on here:
>
> https://lore.kernel.org/linux-nvme/aGvuRS8VmC0JXAR3@kbusch-mbp/
>
Regarding the checks you listed, they seem too restrictive. They only support
AWUPF for single-controller devices and for disks that either have only one
namespace or support formatting all namespaces together (i.e., do not support
formatting individual namespaces).
> I just don't know if you know of any devices where that criteria doesn't
> git. If not, maybe we can work with that without introducing more user
> knobs.
Given this, IMO, an opt-in approach should be considered, letting users
decide whether they want to enable atomic write support or not.
Thanks,
--Nilay
next prev parent reply other threads:[~2025-08-21 5:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-20 15:02 [RFC PATCH] nvme: add an opt-in to use AWUPF John Garry
2025-08-20 21:51 ` Keith Busch
2025-08-21 5:25 ` Nilay Shroff [this message]
2025-08-21 13:42 ` Keith Busch
2025-08-21 8:38 ` Christoph Hellwig
2025-08-21 10:56 ` John Garry
2025-08-21 8:35 ` Christoph Hellwig
2025-08-21 10:33 ` John Garry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b8156bb1-b7fe-4036-9dbb-98fdcec3ff65@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=axboe@kernel.dk \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=john.g.garry@oracle.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=martin.petersen@oracle.com \
--cc=mcgrof@infradead.org \
--cc=sagi@grimberg.me \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox