Re: [PATCH] xfs: fix fallback data device flush for realtime inodes
From: Hongling Zeng
Date: Wed Jul 29 2026 - 05:07:46 EST
在 2026年07月29日 16:34, Christoph Hellwig 写道:
On Wed, Jul 29, 2026 at 03:39:18PM +0800, Hongling Zeng wrote:Thanks for the explanation.
xfs_file_fsync() has a fallback flush for the case where the log forceNo. The rt device is flushed before the called to xfs_fsync_flush_log,
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.
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.
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.