All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Carlos Maiolino <cem@kernel.org>,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/6] xfs: pass the write pointer to xfs_init_zone
Date: Mon, 12 Jan 2026 13:50:08 -0800	[thread overview]
Message-ID: <20260112215008.GD15551@frogsfrogsfrogs> (raw)
In-Reply-To: <ce23e24a-d671-43bc-a5e1-28ccf7083aff@kernel.org>

On Mon, Jan 12, 2026 at 11:15:07AM +0100, Damien Le Moal wrote:
> On 1/9/26 18:20, Christoph Hellwig wrote:
> > Move the two methods to query the write pointer out of xfs_init_zone into
> > the callers, so that xfs_init_zone doesn't have to bother with the
> > blk_zone structure and instead operates purely at the XFS realtime group
> > level.
> > 
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> >  fs/xfs/xfs_zone_alloc.c | 66 +++++++++++++++++++++++------------------
> >  1 file changed, 37 insertions(+), 29 deletions(-)
> > 
> > diff --git a/fs/xfs/xfs_zone_alloc.c b/fs/xfs/xfs_zone_alloc.c
> > index bbcf21704ea0..013228eab0ac 100644
> > --- a/fs/xfs/xfs_zone_alloc.c
> > +++ b/fs/xfs/xfs_zone_alloc.c
> > @@ -981,43 +981,43 @@ struct xfs_init_zones {
> >  	uint64_t		reclaimable;
> >  };
> >  
> > +/*
> > + * For sequential write required zones, we restart writing at the hardware write
> > + * pointer.
> > + *
> > + * For conventional zones or conventional devices we have query the rmap to
> > + * find the highest recorded block and set the write pointer to the block after
> > + * that.  In case of a power loss this misses blocks where the data I/O has
> > + * completed but not recorded in the rmap yet, and it also rewrites blocks if
> > + * the most recently written ones got deleted again before unmount, but this is
> > + * the best we can do without hardware support.
> > + */
> 
> I find this comment and the function name confusing since we are not looking at
> a zone write pointer at all. So maybe rename this to something like:
> 
> xfs_rmap_get_highest_rgbno()
> 
> ? Also, I think the comment block should go...
> 
> > +static xfs_rgblock_t
> > +xfs_rmap_write_pointer(
> > +	struct xfs_rtgroup	*rtg)
> > +{
> > +	xfs_rgblock_t		highest_rgbno;
> > +
> > +	xfs_rtgroup_lock(rtg, XFS_RTGLOCK_RMAP);
> > +	highest_rgbno = xfs_rtrmap_highest_rgbno(rtg);
> > +	xfs_rtgroup_unlock(rtg, XFS_RTGLOCK_RMAP);
> > +
> > +	if (highest_rgbno == NULLRGBLOCK)
> > +		return 0;
> > +	return highest_rgbno + 1;
> > +}
> 
> [...]
> 
> >  	/*
> >  	 * If there are no used blocks, but the zone is not in empty state yet
> >  	 * we lost power before the zoned reset.  In that case finish the work
> > @@ -1066,6 +1066,7 @@ xfs_get_zone_info_cb(
> >  	struct xfs_mount	*mp = iz->mp;
> >  	xfs_fsblock_t		zsbno = xfs_daddr_to_rtb(mp, zone->start);
> >  	xfs_rgnumber_t		rgno;
> > +	xfs_rgblock_t		write_pointer;
> >  	struct xfs_rtgroup	*rtg;
> >  	int			error;
> >  
> > @@ -1080,7 +1081,13 @@ xfs_get_zone_info_cb(
> >  		xfs_warn(mp, "realtime group not found for zone %u.", rgno);
> >  		return -EFSCORRUPTED;
> >  	}
> > -	error = xfs_init_zone(iz, rtg, zone);
> 
> ...here.
> This code is also hard to follow without a comment indicating that write_pointer
> is not set by xfs_zone_validate() for conventional zones. Ideally, we should
> move the call to xfs_rmap_write_pointer() in xfs_zone_validate(). That would be
> cleaner, no ?
> 
> > +	if (!xfs_zone_validate(zone, rtg, &write_pointer)) {

I had wondered by the time I got to the end of this series if this
function should be renamed to xfs_validate_hw_zone() or something like
that?

--D

> > +		xfs_rtgroup_rele(rtg);
> > +		return -EFSCORRUPTED;
> > +	}
> > +	if (zone->cond == BLK_ZONE_COND_NOT_WP)
> > +		write_pointer = xfs_rmap_write_pointer(rtg);
> > +	error = xfs_init_zone(iz, rtg, write_pointer);
> >  	xfs_rtgroup_rele(rtg);
> >  	return error;
> >  }
> > @@ -1290,7 +1297,8 @@ xfs_mount_zones(
> >  		struct xfs_rtgroup	*rtg = NULL;
> >  
> >  		while ((rtg = xfs_rtgroup_next(mp, rtg))) {
> > -			error = xfs_init_zone(&iz, rtg, NULL);
> > +			error = xfs_init_zone(&iz, rtg,
> > +					xfs_rmap_write_pointer(rtg));
> >  			if (error) {
> >  				xfs_rtgroup_rele(rtg);
> >  				goto out_free_zone_info;
> 
> 
> -- 
> Damien Le Moal
> Western Digital Research
> 

  reply	other threads:[~2026-01-12 21:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-09 17:20 refactor zone reporting Christoph Hellwig
2026-01-09 17:20 ` [PATCH 1/6] xfs: add missing forward declaration in xfs_zones.h Christoph Hellwig
2026-01-10  0:50   ` Darrick J. Wong
2026-01-09 17:20 ` [PATCH 2/6] xfs: add a xfs_rtgroup_raw_size helper Christoph Hellwig
2026-01-10  1:00   ` Darrick J. Wong
2026-01-09 17:20 ` [PATCH 3/6] xfs: pass the write pointer to xfs_init_zone Christoph Hellwig
2026-01-10  1:11   ` Darrick J. Wong
2026-01-12 10:15   ` Damien Le Moal
2026-01-12 21:50     ` Darrick J. Wong [this message]
2026-01-13  7:47       ` Christoph Hellwig
2026-01-13  7:47     ` Christoph Hellwig
2026-01-13  9:27       ` Damien Le Moal
2026-01-09 17:20 ` [PATCH 4/6] xfs: split and refactor zone validation Christoph Hellwig
2026-01-10  1:44   ` Darrick J. Wong
2026-01-12 10:12     ` Christoph Hellwig
2026-01-09 17:20 ` [PATCH 5/6] xfs: check that used blocks are smaller than the write pointer Christoph Hellwig
2026-01-10  1:25   ` Darrick J. Wong
2026-01-09 17:20 ` [PATCH 6/6] xfs: use blkdev_get_zone_info to simply zone reporting Christoph Hellwig
2026-01-10  1:28   ` Darrick J. Wong
2026-01-13 10:33   ` Damien Le Moal
  -- strict thread matches above, loose matches on Subject: below --
2026-01-14  6:53 refactor zone reporting v2 Christoph Hellwig
2026-01-14  6:53 ` [PATCH 3/6] xfs: pass the write pointer to xfs_init_zone Christoph Hellwig
2026-01-14 10:00   ` Damien Le Moal
2026-01-16 14:16   ` Carlos Maiolino

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=20260112215008.GD15551@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=cem@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=hch@lst.de \
    --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 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.