* Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required [not found] ` <20251029155306.GC3356773@frogsfrogsfrogs> @ 2025-10-29 16:35 ` Christoph Hellwig 2025-10-29 21:23 ` Qu Wenruo 0 siblings, 1 reply; 9+ messages in thread From: Christoph Hellwig @ 2025-10-29 16:35 UTC (permalink / raw) To: Darrick J. Wong Cc: Christoph Hellwig, Carlos Maiolino, Christian Brauner, Jan Kara, Martin K. Petersen, linux-kernel, linux-xfs, linux-fsdevel, linux-raid, linux-block, Qu Wenruo, linux-btrfs [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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required 2025-10-29 16:35 ` [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required Christoph Hellwig @ 2025-10-29 21:23 ` Qu Wenruo 2025-10-30 5:58 ` Christoph Hellwig 0 siblings, 1 reply; 9+ messages in thread From: Qu Wenruo @ 2025-10-29 21:23 UTC (permalink / raw) To: Christoph Hellwig, Darrick J. Wong Cc: Carlos Maiolino, Christian Brauner, Jan Kara, Martin K. Petersen, linux-kernel, linux-xfs, linux-fsdevel, linux-raid, linux-block, linux-btrfs 在 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. > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required 2025-10-29 21:23 ` Qu Wenruo @ 2025-10-30 5:58 ` Christoph Hellwig 2025-10-30 6:37 ` Qu Wenruo 0 siblings, 1 reply; 9+ messages in thread From: Christoph Hellwig @ 2025-10-30 5:58 UTC (permalink / raw) To: Qu Wenruo Cc: Christoph Hellwig, Darrick J. Wong, Carlos Maiolino, Christian Brauner, Jan Kara, Martin K. Petersen, linux-kernel, linux-xfs, linux-fsdevel, linux-raid, linux-block, linux-btrfs 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required 2025-10-30 5:58 ` Christoph Hellwig @ 2025-10-30 6:37 ` Qu Wenruo 2025-10-30 6:49 ` Christoph Hellwig 0 siblings, 1 reply; 9+ messages in thread From: Qu Wenruo @ 2025-10-30 6:37 UTC (permalink / raw) To: Christoph Hellwig, Qu Wenruo Cc: Darrick J. Wong, Carlos Maiolino, Christian Brauner, Jan Kara, Martin K. Petersen, linux-kernel, linux-xfs, linux-fsdevel, linux-raid, linux-block, linux-btrfs 在 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required 2025-10-30 6:37 ` Qu Wenruo @ 2025-10-30 6:49 ` Christoph Hellwig 2025-10-30 6:53 ` Qu Wenruo 0 siblings, 1 reply; 9+ messages in thread From: Christoph Hellwig @ 2025-10-30 6:49 UTC (permalink / raw) To: Qu Wenruo Cc: Christoph Hellwig, Qu Wenruo, Darrick J. Wong, Carlos Maiolino, Christian Brauner, Jan Kara, Martin K. Petersen, linux-kernel, linux-xfs, linux-fsdevel, linux-raid, linux-block, linux-btrfs 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--- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required 2025-10-30 6:49 ` Christoph Hellwig @ 2025-10-30 6:53 ` Qu Wenruo 2025-10-30 6:55 ` Christoph Hellwig 0 siblings, 1 reply; 9+ messages in thread From: Qu Wenruo @ 2025-10-30 6:53 UTC (permalink / raw) To: Christoph Hellwig, Qu Wenruo Cc: Darrick J. Wong, Carlos Maiolino, Christian Brauner, Jan Kara, Martin K. Petersen, linux-kernel, linux-xfs, linux-fsdevel, linux-raid, linux-block, linux-btrfs 在 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--- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required 2025-10-30 6:53 ` Qu Wenruo @ 2025-10-30 6:55 ` Christoph Hellwig 2025-10-30 7:14 ` Qu Wenruo 0 siblings, 1 reply; 9+ messages in thread From: Christoph Hellwig @ 2025-10-30 6:55 UTC (permalink / raw) To: Qu Wenruo Cc: Christoph Hellwig, Qu Wenruo, Darrick J. Wong, Carlos Maiolino, Christian Brauner, Jan Kara, Martin K. Petersen, linux-kernel, linux-xfs, linux-fsdevel, linux-raid, linux-block, linux-btrfs 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required 2025-10-30 6:55 ` Christoph Hellwig @ 2025-10-30 7:14 ` Qu Wenruo 2025-10-30 7:17 ` Christoph Hellwig 0 siblings, 1 reply; 9+ messages in thread From: Qu Wenruo @ 2025-10-30 7:14 UTC (permalink / raw) To: Christoph Hellwig, Qu Wenruo Cc: Darrick J. Wong, Carlos Maiolino, Christian Brauner, Jan Kara, Martin K. Petersen, linux-kernel, linux-xfs, linux-fsdevel, linux-raid, linux-block, linux-btrfs 在 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required 2025-10-30 7:14 ` Qu Wenruo @ 2025-10-30 7:17 ` Christoph Hellwig 0 siblings, 0 replies; 9+ messages in thread From: Christoph Hellwig @ 2025-10-30 7:17 UTC (permalink / raw) To: Qu Wenruo Cc: Christoph Hellwig, Darrick J. Wong, Carlos Maiolino, Christian Brauner, Jan Kara, Martin K. Petersen, linux-kernel, linux-xfs, linux-fsdevel, linux-raid, linux-block, linux-btrfs 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2025-10-30 7:17 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20251029071537.1127397-1-hch@lst.de>
[not found] ` <20251029071537.1127397-5-hch@lst.de>
[not found] ` <20251029155306.GC3356773@frogsfrogsfrogs>
2025-10-29 16:35 ` [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required Christoph Hellwig
2025-10-29 21:23 ` Qu Wenruo
2025-10-30 5:58 ` Christoph Hellwig
2025-10-30 6:37 ` Qu Wenruo
2025-10-30 6:49 ` Christoph Hellwig
2025-10-30 6:53 ` Qu Wenruo
2025-10-30 6:55 ` Christoph Hellwig
2025-10-30 7:14 ` Qu Wenruo
2025-10-30 7:17 ` Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox