[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aQTcb-0VtWLx6ghD@kbusch-mbp>
Date: Fri, 31 Oct 2025 09:57:35 -0600
From: Keith Busch <kbusch@...nel.org>
To: Christoph Hellwig <hch@....de>
Cc: Dave Chinner <david@...morbit.com>, Carlos Maiolino <cem@...nel.org>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
linux-kernel@...r.kernel.org, linux-xfs@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-raid@...r.kernel.org,
linux-block@...r.kernel.org
Subject: Re: fall back from direct to buffered I/O when stable writes are
required
On Fri, Oct 31, 2025 at 02:00:50PM +0100, Christoph Hellwig wrote:
> On Fri, Oct 31, 2025 at 10:18:46AM +1100, Dave Chinner wrote:
>
> > Modifying an IO buffer whilst a DIO is in flight on that buffer has
> > -always- been an application bug.
>
> Says who?
Not sure of any official statement to that effect, but storage in
general always says the behavior of modifying data concurrently with
in-flight operations on that data produces non-deterministic results. An
application with such behavior sounds like a bug to me as I can't
imagine anyone purposefully choosing to persist data with a random
outcome. If PI is enabled, I think they'd rather get a deterministic
guard check error so they know they did something with undefined
behavior.
It's like having reads and writes to overlapping LBA and/or memory
ranges concurrently outstanding. There's no guaranteed result there
either; specs just say it's the host's responsibilty to not do that.
The kernel doesn't stop an application from trying that on raw block
direct-io, but I'd say that's an application bug.
Powered by blists - more mailing lists