Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required

Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required

[Christoph Hellwig]

[Adding Qu and the btrfs list]

On Wed, Oct 29, 2025 at 08:53:06AM -0700, Darrick J. Wong wrote:
> > +	if (mapping_stable_writes(iocb->ki_filp->f_mapping)) {
> > +		xfs_info_once(mp,
> > +			"falling back from direct to buffered I/O for write");
> > +		return -ENOTBLK;
> > +	}
> 
> /me wonders if the other filesystems will have to implement this same
> fallback and hence this should be a common helper ala
> dio_warn_stale_pagecache?  But we'll get there when we get there.

As far as I'm concerned they should.  Btrfs in fact has recently done
that, as they are even more exposed due to the integrated checksumming.

So yes, a common helper might make sense.  Especially if we want common
configuration for opt-outs eventually.

> >  	file->f_mode |= FMODE_NOWAIT | FMODE_CAN_ODIRECT;
> > -	file->f_mode |= FMODE_DIO_PARALLEL_WRITE;
> > -	if (xfs_get_atomic_write_min(XFS_I(inode)) > 0)
> > -		file->f_mode |= FMODE_CAN_ATOMIC_WRITE;
> > +	if (!mapping_stable_writes(file->f_mapping)) {
> > +		file->f_mode |= FMODE_DIO_PARALLEL_WRITE;
> 
> Hrm.  So parallel directio writes are disabled for writes to files on
> stable_pages devices because we have to fall back to buffered writes.
> Those serialize on i_rwsem so that's why we don't set
> FMODE_DIO_PARALLEL_WRITE, correct?

Yes.

> There's not some more subtle reason
> for not supporting it, right?

Not that I know of anyway.

Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required

[Qu Wenruo]

在 2025/10/30 03:05, Christoph Hellwig 写道:
> [Adding Qu and the btrfs list]
> 
> On Wed, Oct 29, 2025 at 08:53:06AM -0700, Darrick J. Wong wrote:
>>> +	if (mapping_stable_writes(iocb->ki_filp->f_mapping)) {
>>> +		xfs_info_once(mp,
>>> +			"falling back from direct to buffered I/O for write");
>>> +		return -ENOTBLK;
>>> +	}
>>
>> /me wonders if the other filesystems will have to implement this same
>> fallback and hence this should be a common helper ala
>> dio_warn_stale_pagecache?  But we'll get there when we get there.
> 
> As far as I'm concerned they should.  Btrfs in fact has recently done
> that, as they are even more exposed due to the integrated checksumming.
> 
> So yes, a common helper might make sense.  Especially if we want common
> configuration for opt-outs eventually.

Yep, a common helper will help, or even integrate the check into 
__iomap_dio_rw().

Although btrfs currently uses some btrfs specific flags to do the check, 
we're also setting stable writes flags for the address space, thus we 
can share the same check.

However I'm not sure if a warning will be that useful.

If the warning is only outputted once like here, it doesn't show the ino 
number to tell which file is affected.
If the warning is shown every time, it will flood the dmesg.

It will be much straightforward if there is some flag allowing us to 
return error directly if true zero-copy direct IO can not be executed.

Thanks,
Qu

> 
>>>   	file->f_mode |= FMODE_NOWAIT | FMODE_CAN_ODIRECT;
>>> -	file->f_mode |= FMODE_DIO_PARALLEL_WRITE;
>>> -	if (xfs_get_atomic_write_min(XFS_I(inode)) > 0)
>>> -		file->f_mode |= FMODE_CAN_ATOMIC_WRITE;
>>> +	if (!mapping_stable_writes(file->f_mapping)) {
>>> +		file->f_mode |= FMODE_DIO_PARALLEL_WRITE;
>>
>> Hrm.  So parallel directio writes are disabled for writes to files on
>> stable_pages devices because we have to fall back to buffered writes.
>> Those serialize on i_rwsem so that's why we don't set
>> FMODE_DIO_PARALLEL_WRITE, correct?
> 
> Yes.
> 
>> There's not some more subtle reason
>> for not supporting it, right?
> 
> Not that I know of anyway.
> 

Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required

[Christoph Hellwig]

On Thu, Oct 30, 2025 at 07:53:30AM +1030, Qu Wenruo wrote:
> Yep, a common helper will help, or even integrate the check into 
> __iomap_dio_rw().

Having the check in __iomap_dio_rw would be a last resort, because at
the point we've already done direct I/O specific locking we'd need to
unwind from, making the fallback slower than we'd have to.

> However I'm not sure if a warning will be that useful.
>
> If the warning is only outputted once like here, it doesn't show the ino 
> number to tell which file is affected.
> If the warning is shown every time, it will flood the dmesg.

While the flag is set on the address_space it is global (or semi global
for separate storage pools like the XFS RT device), so the inode number
doesn't really matter too much.

> It will be much straightforward if there is some flag allowing us to return 
> error directly if true zero-copy direct IO can not be executed.

I don't really understand this part.

Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required

[Qu Wenruo]

在 2025/10/30 16:28, Christoph Hellwig 写道:
[...]
>> It will be much straightforward if there is some flag allowing us to return
>> error directly if true zero-copy direct IO can not be executed.
> 
> I don't really understand this part.

I mean some open flag like O_DIRECT_NO_FALLBACK, then we can directly 
reutrn -ENOBLK without falling back to buffered IO (and no need to 
bother the warning of falling back).

This will provide the most accurate, true zero-copy for those programs 
that really require zero-copy.

And we won't need to bother falling back to buffered IO, it will be 
something for the user space to bother.

Thanks,
Qu

Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required

[Christoph Hellwig]

On Thu, Oct 30, 2025 at 05:07:44PM +1030, Qu Wenruo wrote:
> I mean some open flag like O_DIRECT_NO_FALLBACK, then we can directly 
> reutrn -ENOBLK without falling back to buffered IO (and no need to bother 
> the warning of falling back).
>
> This will provide the most accurate, true zero-copy for those programs that 
> really require zero-copy.
>
> And we won't need to bother falling back to buffered IO, it will be 
> something for the user space to bother.

So what is your application going to do if the open fails?

>
> Thanks,
> Qu
---end quoted text---

Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required

[Qu Wenruo]

在 2025/10/30 17:19, Christoph Hellwig 写道:
> On Thu, Oct 30, 2025 at 05:07:44PM +1030, Qu Wenruo wrote:
>> I mean some open flag like O_DIRECT_NO_FALLBACK, then we can directly
>> reutrn -ENOBLK without falling back to buffered IO (and no need to bother
>> the warning of falling back).
>>
>> This will provide the most accurate, true zero-copy for those programs that
>> really require zero-copy.
>>
>> And we won't need to bother falling back to buffered IO, it will be
>> something for the user space to bother.
> 
> So what is your application going to do if the open fails?

If it can not accept buffered fallback, error out.

If it can, do regular open without direct IO flags, and may be even open 
a bug report to the project, questioning if they really need direct IO 
in the first place.

Thanks,
Qu

> 
>>
>> Thanks,
>> Qu
> ---end quoted text---

Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required

[Christoph Hellwig]

On Thu, Oct 30, 2025 at 05:23:32PM +1030, Qu Wenruo wrote:
>> So what is your application going to do if the open fails?
>
> If it can not accept buffered fallback, error out.

Why would it not be able to accept that?

Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required

[Qu Wenruo]

在 2025/10/30 17:25, Christoph Hellwig 写道:
> On Thu, Oct 30, 2025 at 05:23:32PM +1030, Qu Wenruo wrote:
>>> So what is your application going to do if the open fails?
>>
>> If it can not accept buffered fallback, error out.
> 
> Why would it not be able to accept that?
> 

Because for whatever reasons, although the only reason I can come up 
with is performance.

I thought the old kernel principle is, providing the mechanism not the 
policy.
But the fallback-to-buffered looks more like a policy, and if that's the 
case user space should be more suitable.

Thanks,
Qu

Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required

[Christoph Hellwig]

On Thu, Oct 30, 2025 at 05:44:22PM +1030, Qu Wenruo wrote:
> Because for whatever reasons, although the only reason I can come up with 
> is performance.
>
> I thought the old kernel principle is, providing the mechanism not the 
> policy.
> But the fallback-to-buffered looks more like a policy, and if that's the 
> case user space should be more suitable.

I don't think so.  O_DIRECT really is a hint.  We already do fallbacks
for various reasons (for XFS e.g. unaligned writes on COW files), and
btrfs in fact falls back for any alignment mismatch already.  And there's
really nothing an application can do when the most optimal way is not
available except for using a less optimal one.  So there's really no
value add for an option to fail.