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

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

[Hongling Zeng]

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.

Use xfs_inode_buftarg(ip) to obtain the actual data target for the inode,
and perform the fallback flush when the log force did not flush anything
and the log target is the same as that data target.

This preserves the existing behavior for regular inodes while allowing
the fallback flush to cover realtime inodes whose data target shares the
log device.

Fixes: 2291dab2c9d1 ("xfs: Always flush caches when integrity is required")
Cc: stable@vger.kernel.org
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
 fs/xfs/xfs_file.c | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 0ade13b31335..2a6186f67979 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -166,17 +166,22 @@ xfs_file_fsync(
 	}
 
 	/*
-	 * If we only have a single device, and the log force about was
-	 * a no-op we might have to flush the data device cache here.
-	 * This can only happen for fdatasync/O_DSYNC if we were overwriting
-	 * an already allocated file and thus do not have any metadata to
-	 * commit.
+	 * If the log force was a no-op, we may still need to flush the
+	 * data device cache for fdatasync/O_DSYNC overwrites of already
+	 * allocated file data with no metadata updates.
+	 *
+	 * Use the inode's actual data target (which may be the RT device
+	 * for realtime inodes) and flush only if it shares the device
+	 * with the log target.
 	 */
-	if (!log_flushed && !XFS_IS_REALTIME_INODE(ip) &&
-	    mp->m_logdev_targp == mp->m_ddev_targp) {
-		err2 = blkdev_issue_flush(mp->m_ddev_targp->bt_bdev);
-		if (err2 && !error)
-			error = err2;
+	if (!log_flushed) {
+		struct xfs_buftarg *data_targp = xfs_inode_buftarg(ip);
+
+		if (mp->m_logdev_targp == data_targp) {
+			err2 = blkdev_issue_flush(data_targp->bt_bdev);
+			if (err2 && !error)
+				error = err2;
+		}
 	}
 
 	return error;
-- 
2.25.1

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

[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.

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

[Hongling Zeng]

在 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.

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

[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?