All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pankaj Raghav (Samsung)" <pankaj.raghav@linux.dev>
To: Daejun Park <daejun7.park@samsung.com>
Cc: Carlos Maiolino <cem@kernel.org>,
	linux-xfs@vger.kernel.org,  Christoph Hellwig <hch@lst.de>,
	"Darrick J. Wong" <djwong@kernel.org>,
	 Dave Chinner <dgc@kernel.org>, Chuck Lever <cel@kernel.org>,
	Jeff Layton <jlayton@kernel.org>,  Dai Ngo <Dai.Ngo@oracle.com>,
	Sergey Bashirov <sergeybashirov@gmail.com>,
	 Andrey Albershteyn <aalbersh@kernel.org>,
	linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	 stable@vger.kernel.org
Subject: Re: [PATCH v4 2/9] xfs: add a flag to convert unwritten extents without allocating blocks
Date: Thu, 22 Oct 2026 14:43:50 +0200	[thread overview]
Message-ID: <atoEubjhGZgA2WQk@quentin> (raw)
In-Reply-To: <20261020-xfs-pnfs-batch-v4-2-9230fa2ca4a4@samsung.com>

On Tue, Oct 20, 2026 at 12:08:45PM +0900, Daejun Park wrote:
> xfs_bmapi_write() with XFS_BMAPI_CONVERT converts unwritten extents to
> written ones, and allocates blocks for any hole or delalloc extent it
> finds in the range. A caller that may only convert blocks that are
> already allocated has to look at the mapping first, and the mapping can
> change once the ILOCK is dropped.
> 
> Add XFS_BMAPI_CONVERT_ONLY. With it, xfs_bmapi_write() stops at a hole
> or a delalloc extent instead of allocating blocks and returns the
> mappings that it converted before it. If the range starts with a hole or
> a delalloc extent, it returns -ENOSR, as it does when a delalloc
> conversion maps nothing in the range. Nothing has been changed then, and
> the caller decides what to do with its transaction.
> 
> A flag of this name was removed by commit 26b91c728b2d ("xfs: make COW
> fork unwritten extent conversions more robust"). That one skipped the
> allocation and still mapped the hole; this one stops before it.
> 
> "xfs: refuse a pNFS LAYOUTCOMMIT of a range without blocks" uses it,
> which is why this is marked for stable.
> 
> Suggested-by: Christoph Hellwig <hch@lst.de>
> Link: https://lore.kernel.org/r/20261013120359.GB2944@lst.de
> Cc: stable@vger.kernel.org
> Signed-off-by: Daejun Park <daejun7.park@samsung.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/xfs/libxfs/xfs_bmap.c | 14 ++++++++++++--
>  fs/xfs/libxfs/xfs_bmap.h | 10 +++++++++-
>  2 files changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
> index ca49bf4a50..95c0178b44 100644
> --- a/fs/xfs/libxfs/xfs_bmap.c
> +++ b/fs/xfs/libxfs/xfs_bmap.c
> @@ -4130,6 +4130,8 @@ xfs_bmapi_finish(
>   * Returns a negative error code on failure, including -ENOSPC when it could not
>   * allocate any blocks and -ENOSR when it did allocate blocks to convert a
>   * delalloc range, but those blocks were before the passed in range.
> + * With XFS_BMAPI_CONVERT_ONLY, it stops at a hole or a delalloc extent instead
> + * of allocating blocks, and returns -ENOSR if it stops before mapping anything.
>   */
>  int
>  xfs_bmapi_write(
> @@ -4189,6 +4191,8 @@ xfs_bmapi_write(
>  	 */
>  	ASSERT((flags & (XFS_BMAPI_PREALLOC | XFS_BMAPI_ZERO)) !=
>  			(XFS_BMAPI_PREALLOC | XFS_BMAPI_ZERO));
> +	ASSERT(!(flags & XFS_BMAPI_CONVERT_ONLY) ||
> +	       (flags & XFS_BMAPI_CONVERT));
>  
>  	if (XFS_IS_CORRUPT(mp, !xfs_ifork_has_extents(ifp)) ||
>  	    XFS_TEST_ERROR(mp, XFS_ERRTAG_BMAPIFORMAT)) {
> @@ -4237,6 +4241,9 @@ xfs_bmapi_write(
>  		 * that we found, if any.
>  		 */
>  		if (need_alloc || wasdelay) {
> +			if (flags & XFS_BMAPI_CONVERT_ONLY)
> +				break;
> +
>  			bma.eof = eof;
>  			bma.conv = !!(flags & XFS_BMAPI_CONVERT);
>  			bma.wasdel = wasdelay;
> @@ -4332,10 +4339,13 @@ xfs_bmapi_write(
>  	 *
>  	 * To avoid a successful return with *nmap set to 0, return the magic
>  	 * -ENOSR error code for this particular case so that the caller can
> -	 * handle it.
> +	 * handle it. The same goes for XFS_BMAPI_CONVERT_ONLY stopping at a
> +	 * hole or a delalloc extent at the start of the range, in which case
> +	 * nothing has been changed.
>  	 */
>  	if (!n) {
> -		ASSERT(bma.nallocs >= *nmap);
> +		ASSERT(bma.nallocs >= *nmap ||
> +		       (flags & XFS_BMAPI_CONVERT_ONLY));
Minor nit:

The following might be more explicit here:

ASSERT((flags & XFS_BMAPI_CONVERT_ONLY) ? bma.nallocs == 0 :
                                         bma.nallocs >= *nmap);

Otherwise, the patch looks good.
Reviewed-by: Pankaj Raghav <p.raghav@samsung.com>

-- 
Pankaj

  reply	other threads:[~2026-10-22 12:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20  3:08 [PATCH v4 0/9] xfs: pNFS block layout fixes Daejun Park
2026-10-20  3:08 ` Daejun Park via B4 Relay
2026-10-20  3:08 ` [PATCH v4 1/9] xfs: mark the inode preallocated for pNFS write layouts past EOF Daejun Park
2026-10-20  3:08   ` Daejun Park via B4 Relay
2026-10-22 12:41   ` Pankaj Raghav (Samsung)
2026-10-20  3:08 ` [PATCH v4 2/9] xfs: add a flag to convert unwritten extents without allocating blocks Daejun Park
2026-10-20  3:08   ` Daejun Park via B4 Relay
2026-10-22 12:43   ` Pankaj Raghav (Samsung) [this message]
2026-10-27  8:31     ` Daejun Park
2026-10-20  3:08 ` [PATCH v4 3/9] xfs: refuse a pNFS LAYOUTCOMMIT of a range without blocks Daejun Park
2026-10-20  3:08   ` Daejun Park via B4 Relay
2026-10-20  3:08 ` [PATCH v4 4/9] xfs: clamp a pNFS LAYOUTCOMMIT extent before computing its end Daejun Park
2026-10-20  3:08   ` Daejun Park via B4 Relay
2026-10-22 12:44   ` Pankaj Raghav (Samsung)
2026-10-20  3:08 ` [PATCH v4 5/9] xfs: limit the count of a pNFS write allocation to one extent Daejun Park
2026-10-20  3:08   ` Daejun Park via B4 Relay
2026-10-22 13:02   ` Pankaj Raghav (Samsung)
2026-10-27  8:35     ` Daejun Park
2026-10-28 16:13     ` Christoph Hellwig
2026-10-20  3:08 ` [PATCH v4 6/9] xfs: clamp the pNFS layout range to the maximum file size Daejun Park
2026-10-20  3:08   ` Daejun Park via B4 Relay
2026-10-23 11:10   ` Pankaj Raghav (Samsung)
2026-10-28 16:10   ` Christoph Hellwig
2026-10-20  3:08 ` [PATCH v4 7/9] xfs: take the invalidate lock while mapping a pNFS layout Daejun Park
2026-10-20  3:08   ` Daejun Park via B4 Relay
2026-10-20  3:08 ` [PATCH v4 8/9] xfs: add datasync and log_flushed arguments to xfs_log_force_inode() Daejun Park
2026-10-20  3:08   ` Daejun Park via B4 Relay
2026-10-28 16:12   ` Christoph Hellwig
2026-10-20  3:08 ` [PATCH v4 9/9] xfs: make pNFS LAYOUTCOMMIT stable the way fdatasync does Daejun Park
2026-10-20  3:08   ` Daejun Park via B4 Relay

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=atoEubjhGZgA2WQk@quentin \
    --to=pankaj.raghav@linux.dev \
    --cc=Dai.Ngo@oracle.com \
    --cc=aalbersh@kernel.org \
    --cc=cel@kernel.org \
    --cc=cem@kernel.org \
    --cc=daejun7.park@samsung.com \
    --cc=dgc@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=jlayton@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sergeybashirov@gmail.com \
    --cc=stable@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.