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

[Hongling Zeng <zhongling0719@126.com>]

在 2026年07月29日 16:34, Christoph Hellwig 写道:
> On Wed, Jul 29, 2026 at 03:39:18PM +0800, Hongling Zeng wrote:
>> xfs_file_fsync() has a fallback flush for the case where the log force
>> was a no-op, for example fdatasync/O_DSYNC overwrites of already
>> allocated file data with no metadata updates.
>>
>> The current fallback path is limited to non-realtime inodes and always
>> flushes mp->m_ddev_targp. This misses realtime inodes whose data target
>> is selected by the inode and may be mp->m_rtdev_targp.
> No.  The rt device is flushed before the called to xfs_fsync_flush_log,
> as we need to ensure that the data is flushed from the cache before
> the log commit.  For the data device, the REQ_PREFLUSH case takes
> care that.  After xfs_fsync_flush_log we only need to take care of
> the data device if the file is on the data device and the cache
> wasn't flushed as part of the log commit.
Thanks for the explanation.

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.

If such a configuration is impossible by design, then my patch is wrong.

Thanks for clarifying.