Re: [PATCH] xfs: fix fallback data device flush for realtime inodes

[Hongling Zeng <zhongling0719@126.com>]

在 2026年07月29日 22:28, Christoph Hellwig 写道:
> 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?
Thanks for the explanation.

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.