Re: [GIT PULLBOMB v5.6] xfs: metadata directories and realtime groups

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx> # 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@xxxxxxxxxx>
>          Reviewed-by: Christoph Hellwig <hch@xxxxxx>
>      
>       ## 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@xxxxxxxxxx>
>     +    Signed-off-by: Christoph Hellwig <hch@xxxxxx>
>          Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx>
>     +    [djwong: fix the SoB tag from hch, somehow my scripts replaced it...]
>          Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
>      
>       ## 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@xxxxxx>
>     -    Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx>
>          Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
>     +    Reviewed-by: Christoph Hellwig <hch@xxxxxx>

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@xxxxxx>
>     -    Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx>
>          Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
>     +    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
>      
>       ## 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
> 




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux