All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: John Garry <john.g.garry@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
	Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-block@vger.kernel.org, linux-nvme@lists.infradead.org
Subject: Re: Do we need an opt-in for file systems use of hw atomic writes?
Date: Tue, 19 Aug 2025 07:43:47 -0700	[thread overview]
Message-ID: <20250819144347.GC7942@frogsfrogsfrogs> (raw)
In-Reply-To: <59a0d2df-a633-4f82-8b11-147ba88b7bcb@oracle.com>

On Tue, Aug 19, 2025 at 03:36:33PM +0100, John Garry wrote:
> On 19/08/2025 14:39, Christoph Hellwig wrote:
> > On Tue, Aug 19, 2025 at 12:42:01PM +0100, John Garry wrote:
> > > nothing has been happening on this thread for a while. I figure that it is
> > > because we have no good or obvious options.
> > > 
> > > I think that it's better deal with the NVMe driver handling of AWUPF first,
> > > as this applies to block fops as well.
> > > 
> > > As for the suggestion to have an opt-in to use AWUPF, you wrote above that
> > > users may not know when to enable this opt-in or not.
> > > 
> > > It seems to me that we can give the option, but clearly label that it is
> > > potentially dangerous. Hopefully the $RANDOMUSER with the $CHEAPO SSD will
> > > be wise and steer clear.
> > > 
> > > If we always ignore AWUPF, I fear that lots of sound NVMe implementations
> > > will be excluded from HW atomics.
> > 
> > I think ignoring AWUPF is a good idea, but I've also hard some folks
> > not liking that.
> 
> Disabling reading AWUPF would be the best way to know that for sure :)

What is the likelihood of convincing the nvme standards folks to add a
new command for write-untorn that doesn't just silently fail if you get
the parameters wrong?

> > The reason why I prefer a mount option is because we add that to fstab
> > and the kernel command line easily.  For block layer or driver options
> > we'd either need a sysfs file which is always annoying to apply at boot
> > time,

(Yuck, mount options, look how poorly that went for dax= ;))

> Could system-udev auto enable for us via sysfs file or ioctl?

Userspace controllable sysfs configuration knobs like discard_max_bytes
and discard_max_hw_bytes work well with that model.  The nvme layer can
set atomic_write_bytes to zero by default, and a udev rule can change it
up to atomic_write_max_hw_bytes.

That's not /so/ bad if you can either get the udev rulefile merged into
systemd, or dropped in via clod-init or something.

--D

> > or a module option which has the downside of applying to all
> > devices.
> 
> About the mount option, I suppose that it won't do much harm - it's just a
> bit of extra work to configure.
> 
> I just fear that admins will miss enabling it or not enable it out of doubt
> and users won't see the benefit of HW atomics.
> 
> 
> 

  reply	other threads:[~2025-08-19 14:43 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-14 13:17 Do we need an opt-in for file systems use of hw atomic writes? Christoph Hellwig
2025-07-14 13:24 ` Theodore Ts'o
2025-07-14 13:30   ` Christoph Hellwig
2025-07-14 16:04     ` Darrick J. Wong
2025-07-15  6:00       ` Christoph Hellwig
2025-07-15  3:22     ` Martin K. Petersen
2025-07-15  6:00       ` Christoph Hellwig
2025-07-15 12:45         ` Martin K. Petersen
2025-07-14 13:39 ` John Garry
2025-07-14 13:50   ` Christoph Hellwig
2025-07-14 15:53     ` John Garry
2025-07-15  6:02       ` Christoph Hellwig
2025-07-15  8:42         ` John Garry
2025-07-15  9:03           ` Christoph Hellwig
2025-08-19 11:42             ` John Garry
2025-08-19 13:39               ` Christoph Hellwig
2025-08-19 14:36                 ` John Garry
2025-08-19 14:43                   ` Darrick J. Wong [this message]
2025-08-19 14:45                     ` Christoph Hellwig
2025-08-21 14:01               ` Keith Busch
2025-07-15 10:02         ` Christian Brauner
2025-07-15 11:29           ` Christoph Hellwig
2025-07-15 12:20             ` Christian Brauner
2025-07-15 11:58           ` Theodore Ts'o
2025-07-14 20:53 ` Dave Chinner
2025-07-15  6:05   ` Christoph Hellwig
2025-07-15 20:56 ` Keith Busch
2025-07-16  5:50   ` Nilay Shroff

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=20250819144347.GC7942@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=john.g.garry@oracle.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.