All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Hongling Zeng <zhongling0719@126.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Hongling Zeng <zenghongling@kylinos.cn>,
	cem@kernel.org, dchinner@redhat.com, linux-xfs@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] xfs: fix fallback data device flush for realtime inodes
Date: Wed, 29 Jul 2026 07:28:28 -0700	[thread overview]
Message-ID: <amoODOM31YmofPlR@infradead.org> (raw)
In-Reply-To: <6A69C0F0.8010206@126.com>

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?


      reply	other threads:[~2026-07-29 14:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29  7:39 [PATCH] xfs: fix fallback data device flush for realtime inodes Hongling Zeng
2026-07-29  8:34 ` Christoph Hellwig
2026-07-29  8:59   ` Hongling Zeng
2026-07-29 14:28     ` Christoph Hellwig [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amoODOM31YmofPlR@infradead.org \
    --to=hch@infradead.org \
    --cc=cem@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=zenghongling@kylinos.cn \
    --cc=zhongling0719@126.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.