Re: [PATCH] xfs: fix fallback data device flush for realtime inodes
From: Hongling Zeng
Date: Wed Jul 29 2026 - 21:51:18 EST
在 2026年07月29日 22:28, Christoph Hellwig 写道:
On Wed, Jul 29, 2026 at 04:59:28PM +0800, Hongling Zeng wrote:Thanks for the explanation.
I understand that for realtime inodes with a separate RT device, the RTSo the internal RT device does exist, but only when using the zoned
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.
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?
I see now that the internal RT device case only exists with the zoned
allocator, and that zoned writes are out-of-place and therefore always
log inode/bmap updates from I/O completion. So the overwrite/no-metadata
case I described is not the right justification.
I agree that the current code is still inconsistent because the fallback
flush is expressed as "non-RT inode on the data device" rather than in
terms of the inode's actual file data target.
I'll update the commit log accordingly and rename data_targp to
file_targp as suggested.