Re: [PATCH] xfs: fix fallback data device flush for realtime inodes
Christoph Hellwig <[email protected]> Wed, 29 Jul 2026 07:28:28 -0700
| Newsgroups | org.kernel.vger.linux-xfs,org.kernel.vger.linux-kernel,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Jul 29, 2026 at 04:59:28PM +0800, Hongling Zeng wrote: > I understand that for realtime inodes with a separate RT device, the RT > device is flushed before xfs_fsync_flush_log(), and therefore the > post-log fallback path is intentionally limited to data-device files. > > The only case I was worried about is whether it is possible to have a > realtime inode while mp->m_rtdev_targp == mp->m_ddev_targp, i.e. the > realtime data target is effectively the data device. In that case both > the early RT-device flush and the post-log fallback appear to be skipped > when log_flushed == 0. So the internal RT device does exist, but only when using the zoned allocator. And the zoned allocator doesn't support overwrites but always writes out of place, i.e., every data write must log updates to the inode and bmap tree from the I/O completion handler. That being said I agree with your that the current handling is inconsistent. Maybe you can update the commit log based on that?Also maybe rename data_tarp to something like file_targp as data is to close to the "data device" name for the main device?