From: Pankaj Raghav <pankaj.raghav@linux.dev>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-xfs@vger.kernel.org, bfoster@redhat.com, lukas@herbolt.com,
dgc@kernel.org, gost.dev@samsung.com,
Zhang Yi <yi.zhang@huaweicloud.com>,
andres@anarazel.de, kundan.kumar@samsung.com, hch@lst.de,
cem@kernel.org, hch@infradead.org,
Pankaj Raghav <p.raghav@samsung.com>
Subject: Re: [PATCH v8 2/2] xfs: add support for FALLOC_FL_WRITE_ZEROES
Date: Thu, 2 Jul 2026 12:37:31 +0200 [thread overview]
Message-ID: <75dd0085-e847-47de-aa67-a4f714d3d417@linux.dev> (raw)
In-Reply-To: <20260625172006.GC6078@frogsfrogsfrogs>
>> + /*
>> + * 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".
I am not sure what would be the most clean way of solving this issue for rtvol.
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
next prev parent reply other threads:[~2026-07-02 10:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 11:45 [PATCH v8 0/2] add FALLOC_FL_WRITE_ZEROES support to xfs Pankaj Raghav
2026-06-25 11:45 ` [PATCH v8 1/2] xfs: add an allocation mode to xfs_alloc_file_space() Pankaj Raghav
2026-06-25 17:01 ` Darrick J. Wong
2026-06-25 11:45 ` [PATCH v8 2/2] xfs: add support for FALLOC_FL_WRITE_ZEROES Pankaj Raghav
2026-06-25 17:20 ` Darrick J. Wong
2026-06-26 16:04 ` Pankaj Raghav
2026-07-02 10:37 ` Pankaj Raghav [this message]
2026-07-02 16:03 ` Darrick J. Wong
2026-07-02 19:44 ` Pankaj Raghav
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=75dd0085-e847-47de-aa67-a4f714d3d417@linux.dev \
--to=pankaj.raghav@linux.dev \
--cc=andres@anarazel.de \
--cc=bfoster@redhat.com \
--cc=cem@kernel.org \
--cc=dgc@kernel.org \
--cc=djwong@kernel.org \
--cc=gost.dev@samsung.com \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=kundan.kumar@samsung.com \
--cc=linux-xfs@vger.kernel.org \
--cc=lukas@herbolt.com \
--cc=p.raghav@samsung.com \
--cc=yi.zhang@huaweicloud.com \
/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.