Re: [PATCH] xfs: fix fallback data device flush for realtime inodes
Hongling Zeng <[email protected]> Wed, 29 Jul 2026 16:59:28 +0800
| Newsgroups | org.kernel.vger.linux-xfs,org.kernel.vger.linux-kernel,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
在 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.