Re: [PATCH v8 2/2] xfs: add support for FALLOC_FL_WRITE_ZEROES

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Jul 02, 2026 at 12:37:31PM +0200, Pankaj Raghav wrote:
> 
> >> +	/*
> >> +	 * Allocate written, zeroed extents across the range.  xfs_alloc_file_space()
> >> +	 * rounds outward to block granularity:
> >> +	 *  - holes (the punched interior and any unallocated edge block) are
> >> +	 *    allocated and zeroed;
> >> +	 *  - unwritten extents (including unwritten edge blocks) are converted to
> >> +	 *    written and zeroed;
> >> +	 *  - Already written edge blocks are skipped. The out-of-range bytes of
> >> +	 *    a written edge block keep their data (offset_rd -> offset and
> >> +	 *    end -> end_rd); their in-range bytes (offset -> offset_ru and
> >> +	 *    end_ru -> end were already zeroed by xfs_free_file_space().
> >> +	 */
> >> +	return xfs_alloc_file_space(ip, offset, len,
> >> +			XFS_ALLOC_FILE_SPACE_WRITE_ZEROES);
> > 
> > ...and now we can just do an accelerated "write zeroes to disk" which is
> > conveniently always within EOF now.  I /think/ this looks ok to me now,
> > though I'm curious how extensively the new fallocate mode has been
> > tested with fsx and unaligned file ranges?  And rt volumes with rt
> > extent size > 1 fsblock.
> > 
> 
> I am running into an issue with rtvol.
> 
> Ran generic/363 (fsx) on rt, rextsize=2 (4k block / 8k rt extent). First I ran into this:
> 
> xfs_bmap_rtalloc: ASSERT(xfs_extlen_to_rtxmod == 0). WRITE_ZEROES uses
> XFS_BMAPI_CONVERT, and xfs_bmap_extsize_align() bails early on convert, so the
> rt-unaligned range becomes a sub-rt-extent allocation. I fixed it by rounding the alloc range
> out to whole rt extents, like xfs_free_file_space() does for rt extents.
> 
> diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
> index 855602cb35e8..e52ad4c25b66 100644
> --- a/fs/xfs/xfs_bmap_util.c
> +++ b/fs/xfs/xfs_bmap_util.c
> @@ -710,6 +710,13 @@ xfs_alloc_file_space(
>         imapp = &imaps[0];
>         startoffset_fsb = XFS_B_TO_FSBT(mp, offset);
>         endoffset_fsb = XFS_B_TO_FSB(mp, offset + count);
> +
> +       if (mode == XFS_ALLOC_FILE_SPACE_WRITE_ZEROES &&
> +           xfs_inode_has_bigrtalloc(ip)) {
> +               startoffset_fsb = xfs_fileoff_rounddown_rtx(mp, startoffset_fsb);
> +               endoffset_fsb = xfs_fileoff_roundup_rtx(mp, endoffset_fsb);
> +       }
> +
>         allocatesize_fsb = endoffset_fsb - startoffset_fsb;
> 
>         /*
> 
> With that "fixed", I ran into WARN_ON_ONCE(folio_pos > i_size) in iomap_zero_iter,
> via xfs_falloc_setsize -> xfs_setattr_size -> xfs_zero_range. The
> rt-aligned alloc now leaves written zeroed blocks past a non-rt-aligned
> EOF. So WRITE_ZEROES on rtvol breaks "no written blocks past EOF".

Ah, right, because you can't have a dirty folio totally beyond EOF.
I think you have to leave the blocks beyond EOF unwritten, then.

> I am not sure what would be the most clean way of solving this issue for rtvol.

Or I guess you could EOPNOTSUPP :P

--D

> Let me know your thoughts!
> 
> @Zhang yi: did you test this on bigalloc configurations? Maybe you run into a similar problem
> when cluster size (extsize for XFS) > block size?
> 
> --
> Pankaj
>