From: "Darrick J. Wong" <djwong@kernel.org>
To: Carlos Maiolino <cem@kernel.org>
Cc: xfs <linux-xfs@vger.kernel.org>, Christoph Hellwig <hch@infradead.org>
Subject: Re: [GIT PULLBOMB v5.6] xfs: metadata directories and realtime groups
Date: Wed, 13 Nov 2024 22:16:39 -0800 [thread overview]
Message-ID: <20241114061639.GN9438@frogsfrogsfrogs> (raw)
In-Reply-To: <20241114001637.GL9438@frogsfrogsfrogs>
On Wed, Nov 13, 2024 at 04:16:37PM -0800, Darrick J. Wong wrote:
> Hi Carlos,
>
> Please pull these fully reviewed patchsets for kernel 6.13. This
> patchbomb corrects numerous paperwork errors in the v5.5 submission so
> that we can pass linux-next linter.
>
> I have corrected my stgit wrapper program to invoke git checkpatch
> before issuing pull requests. Despite its name, this means I now have
> automated checks for tagging errors in git commits. Freeform text
> fields that require a lot of parsing cleverness to check and that can be
> corrupted easily buc*********.
>
> The following excerpted range diff shows the differences between last
> week's PRs and this week's:
>
> 1: 62027820eb4486 ! 1: 03326f42d6ef7a xfs: fix simplify extent lookup in xfs_can_free_eofblocks
> @@ Commit message
> this patch, we'd invoke xfs_free_eofblocks on first close if anything
> was in the CoW fork. Now we don't do that.
>
> Fix the problem by reverting the removal of the i_delayed_blks check.
>
> Cc: <stable@vger.kernel.org> # v6.12-rc1
> - Fixes: 11f4c3a53adde ("xfs: simplify extent lookup in xfs_can_free_eofblocks")
> + Fixes: 11f4c3a53adde1 ("xfs: simplify extent lookup in xfs_can_free_eofblocks")
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
> ## fs/xfs/xfs_bmap_util.c ##
> @@ fs/xfs/xfs_bmap_util.c: xfs_can_free_eofblocks(
> end_fsb = xfs_rtb_roundup_rtx(mp, end_fsb);
> 2: cd8ae42a82d2d7 = 2: 5bbfaf522b8c42 xfs: fix superfluous clearing of info->low in __xfs_getfsmap_datadev
> ...
> 68: dcfc65befb76df ! 68: 3065c8cf8c7082 xfs: clean up xfs_getfsmap_helper arguments
> @@ Commit message
> fsmap irec structure that contains exactly the data we need, once.
>
> Note that we actually do need rm_startblock for rmap key comparisons
> when we're actually querying an rmap btree, so leave that field but
> document why it's there.
>
> - Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> + Signed-off-by: Christoph Hellwig <hch@lst.de>
> Reviewed-by: Darrick J. Wong <djwong@kernel.org>
> + [djwong: fix the SoB tag from hch, somehow my scripts replaced it...]
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
>
> ## fs/xfs/xfs_fsmap.c ##
> @@ fs/xfs/xfs_fsmap.c: xfs_fsmap_owner_to_rmap(
> }
> return 0;
> 69: 87fe4c34a383d5 = 69: 15165713e812d9 xfs: create incore realtime group structures
> ...
> 83: 1029f08dc53920 ! 83: 08ed382bba4f52 xfs: factor out a xfs_growfs_rt_alloc_fake_mount helper
> @@ Commit message
>
> Note that this changes the rmblocks calculation method to be based
> on the passed in rblocks and extsize and not the explicitly passed
> one, but both methods will always lead to the same result. The new
> version just does a little bit more math while being more general.
>
> - Signed-off-by: Christoph Hellwig <hch@lst.de>
> - Reviewed-by: Darrick J. Wong <djwong@kernel.org>
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> + Reviewed-by: Christoph Hellwig <hch@lst.de>
hch pointed out that I reversed the polarity on this change and the one
after it; both should be From/SOB him, and RVB me. So I'll send a v5.7
with that fixed. Never mind that it's 22:15 and I've been dragged back
to work because we're running the hell out of time. I hate all this
petty bureaucratic shit that's hard to manage.
--D
> ## fs/xfs/xfs_rtalloc.c ##
> @@ fs/xfs/xfs_rtalloc.c: xfs_rtginode_ensure(
>
> if (error != -ENOENT)
> return 0;
> 84: fc233f1fb0588a = 84: bc1cc1849a4bfe xfs: use xfs_growfs_rt_alloc_fake_mount in xfs_growfs_rt_alloc_blocks
> ...
> 110: b91afef724710e ! 110: 2a81329aa08d66 xfs: don't merge ioends across RTGs
> @@ Commit message
> Unlike AGs, RTGs don't always have metadata in their first blocks, and
> thus we don't get automatic protection from merging I/O completions
> across RTG boundaries. Add code to set the IOMAP_F_BOUNDARY flag for
> ioends that start at the first block of a RTG so that they never get
> merged into the previous ioend.
>
> - Signed-off-by: Christoph Hellwig <hch@lst.de>
> - Reviewed-by: Darrick J. Wong <djwong@kernel.org>
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> + Reviewed-by: Christoph Hellwig <hch@lst.de>
>
> ## fs/xfs/libxfs/xfs_rtgroup.h ##
> @@ fs/xfs/libxfs/xfs_rtgroup.h: xfs_rtb_to_rgbno(
> struct xfs_mount *mp,
> xfs_rtblock_t rtbno)
> {
> 111: d162491c5459f4 = 111: 4895d7326c2f49 xfs: make the RT allocator rtgroup aware
> ...
> 139: 13877bc79d8135 = 139: b038df088d5bf2 xfs: port ondisk structure checks from xfs/122 to the kernel
>
> Apologies for the last minute churn and paperwork stress.
>
> --D
>
prev parent reply other threads:[~2024-11-14 6:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-14 0:16 [GIT PULLBOMB v5.6] xfs: metadata directories and realtime groups Darrick J. Wong
2024-11-14 0:17 ` [GIT PULL 01/10] xfs: convert perag to use xarrays Darrick J. Wong
2024-11-14 0:18 ` [GIT PULL 02/10] xfs: create a generic allocation group structure Darrick J. Wong
2024-11-14 0:18 ` [GIT PULL 03/10] xfs: metadata inode directory trees Darrick J. Wong
2024-11-14 0:18 ` [GIT PULL 04/10] xfs: create incore rt allocation groups Darrick J. Wong
2024-11-14 0:18 ` [GIT PULL 05/10] xfs: preparation for realtime " Darrick J. Wong
2024-11-14 0:19 ` [GIT PULL 06/10] xfs: shard the realtime section Darrick J. Wong
2024-11-14 0:19 ` [GIT PULL 07/10] xfs: persist quota options with metadir Darrick J. Wong
2024-11-14 0:19 ` [GIT PULL 08/10] xfs: enable quota for realtime volumes Darrick J. Wong
2024-11-14 0:19 ` [GIT PULL 09/10] xfs: enable metadir Darrick J. Wong
2024-11-14 0:20 ` [GIT PULL 10/10] xfs: improve ondisk structure checks Darrick J. Wong
2024-11-14 6:16 ` Darrick J. Wong [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=20241114061639.GN9438@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=cem@kernel.org \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
/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