From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Chandan Babu R <chandanbabu@kernel.org>,
catherine.hoang@oracle.com, cheng.lin130@zte.com.cn,
dan.j.williams@intel.com, dchinner@redhat.com,
linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
osandov@fb.com, ruansy.fnst@fujitsu.com
Subject: Re: [ANNOUNCE] xfs-linux: for-next updated to 22c2699cb068
Date: Tue, 31 Oct 2023 09:43:59 -0700 [thread overview]
Message-ID: <20231031164359.GA1041814@frogsfrogsfrogs> (raw)
In-Reply-To: <20231031090242.GA25889@lst.de>
On Tue, Oct 31, 2023 at 10:02:42AM +0100, Christoph Hellwig wrote:
> Can you also pick up:
>
> "xfs: only remap the written blocks in xfs_reflink_end_cow_extent"
>
> ?
>
> Also this seems to a bit of a mix of fixes for 6.7 and big stuff that
> is too late for the merge window.
If by 'big stuff' you mean the MF_MEM_PRE_REMOVE patch, then yes, I
agree that it's too late to be changing code outside xfs. Bumping that
to 6.8 will disappoint Shiyang, regrettably.
The patchsets for realtime units refactoring and typechecked rt-helpers
(except for the xfs_rtalloc_args thing) I'd prefer to land in 6.7 for a
few reasons. First, the blast radii are contained to the rtalloc
subsystem of xfs. Second, I've been testing them for nearly a year now,
I think they're ready from a QA perspective.
The third selfish reason for wanting to get the xfs realtime stuff off
my plate is that my goal for 6.8 is to try to eliminate the indirect
->iomap_begin/end calls from iomap. It'll be helpful for me to be able
to focus exclusively on that since I'd really like your help making sure
I do the transition correctly. :)
--D
next prev parent reply other threads:[~2023-10-31 16:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-30 5:46 [ANNOUNCE] xfs-linux: for-next updated to 22c2699cb068 Chandan Babu R
2023-10-31 9:02 ` Christoph Hellwig
2023-10-31 10:47 ` Chandan Babu R
2023-10-31 16:43 ` Darrick J. Wong [this message]
2023-10-31 17:02 ` Chandan Babu R
2023-11-01 11:30 ` Shiyang Ruan
2023-10-31 17:12 ` Christoph Hellwig
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=20231031164359.GA1041814@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=catherine.hoang@oracle.com \
--cc=chandanbabu@kernel.org \
--cc=cheng.lin130@zte.com.cn \
--cc=dan.j.williams@intel.com \
--cc=dchinner@redhat.com \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=osandov@fb.com \
--cc=ruansy.fnst@fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox