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: [GIT PULLBOMB v5.6] xfs: metadata directories and realtime groups
Date: Wed, 13 Nov 2024 16:16:37 -0800 [thread overview]
Message-ID: <20241114001637.GL9438@frogsfrogsfrogs> (raw)
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>
## 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
next reply other threads:[~2024-11-14 0:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-14 0:16 Darrick J. Wong [this message]
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 ` [GIT PULLBOMB v5.6] xfs: metadata directories and realtime groups Darrick J. Wong
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=20241114001637.GL9438@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