Re: fall back from direct to buffered I/O when stable writes are required

Bart Van Assche
2025-10-29T15:58:55Z

On 10/29/25 12:15 AM, Christoph Hellwig wrote:
> we've had a long standing issue that direct I/O to and from devices that
> require stable writes can corrupt data because the user memory can be
> modified while in flight. This series tries to address this by falling
> back to uncached buffered I/O. Given that this requires an extra copy it
> is usually going to be a slow down, especially for very high bandwith
> use cases, so I'm not exactly happy about.
>
> I suspect we need a way to opt out of this for applications that know
> what they are doing, and I can think of a few ways to do that:
>
> 1a) Allow a mount option to override the behavior
>
> This allows the sysadmin to get back to the previous state.
> This is fairly easy to implement, but the scope might be to wide.
>
> 1b) Sysfs attribute
>
> Same as above. Slightly easier to modify, but a more unusual
> interface.
>
> 2) Have a per-inode attribute
>
> Allows to set it on a specific file. Would require an on-disk
> format change for the usual attr options.
>
> 3) Have a fcntl or similar to allow an application to override it
>
> Fine granularity. Requires application change. We might not
> allow any application to force this as it could be used to inject
> corruption.
>
> In other words, they are all kinda horrible.

Hi Christoph,

Has the opposite been considered: only fall back to buffered I/O for
buggy software that modifies direct I/O buffers before I/O has
completed?

Regarding selecting the direct I/O behavior for a process, how about
introducing a new prctl() flag and introducing a new command-line
utility that follows the style of ionice and sets the new flag before
any code runs in the started process?

Thanks,

Bart.