From: Christoph Hellwig <hch@infradead.org>
To: Pankaj Raghav <p.raghav@samsung.com>
Cc: linux-xfs@vger.kernel.org, bfoster@redhat.com, lukas@herbolt.com,
"Darrick J . Wong" <djwong@kernel.org>,
dgc@kernel.org, gost.dev@samsung.com, pankaj.raghav@linux.dev,
andres@anarazel.de, kundan.kumar@samsung.com, cem@kernel.org,
Zhang Yi <yi.zhang@huawei.com>,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
Date: Tue, 16 Jun 2026 06:31:40 -0700 [thread overview]
Message-ID: <ajFQPANpajmFuKpi@infradead.org> (raw)
In-Reply-To: <20260611114029.176200-4-p.raghav@samsung.com>
[API questions for Zhang and -fsdevel/ -api below)
> + unsigned int blksize = i_blocksize(inode);
> + loff_t offset_aligned = round_down(offset, blksize);
I think this actually needs to found up instead of rounding down.
> + /*
> + * Zero the tail of the old EOF block and any space up to the new
> + * offset.
> + * In the usual truncate path, xfs_falloc_setsize takes care of
> + * zeroing those blocks.
> + */
> + if (offset_aligned > old_size) {
> + trace_xfs_zero_eof(ip, old_size, offset_aligned - old_size);
> + error = xfs_zero_range(ip, old_size, offset_aligned - old_size,
> + NULL, &did_zero);
> + if (error)
> + return error;
> + }
... then this will properly zero from the old i_size to the first block
boundary after the old size.
> + error = xfs_alloc_file_space(ip, offset, len,
> + XFS_ALLOC_FILE_SPACE_WRITE_ZEROES);
... and here we need to pass offset_aligned instead of offset and
a new calculated len based on the last block boundary, and then
zero again after that. That is assuming FALLOC_FL_WRITE_ZEROES
allows unaligned ranges for file systems. The block code doesn't,
but I can't quite follow the ext4 code if it does or not, and there
is no mention of FALLOC_FL_WRITE_ZEROES even in the latest man-pages
tree.
Maybe we also want xfstests that try unaligned FALLOC_FL_WRITE_ZEROES
and make sure no existing data before the range is lost and the
entire range is zeroed?
> + if (error)
> + return error;
> +
> + /*
> + * xfs_falloc_setsize() would re-zero the written extents via
> + * iomap_zero_range(). Use xfs_setfilesize() instead.
> + * Update in-core i_size first as xfs_setfilesize() clamps the on-disk
> + * size to it.
> + */
> + if (new_size > i_size_read(inode))
> + i_size_write(inode, new_size);
I think Sashiko is right that we need a pagecache_isize_extended and
filemap_write_and_wait_range calls here.
prev parent reply other threads:[~2026-06-16 13:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 11:40 [PATCH v6 0/3] add FALLOC_FL_WRITE_ZEROES support to xfs Pankaj Raghav
2026-06-11 11:40 ` [PATCH v6 1/3] xfs: widen xfs_setfilesize() size argument to xfs_off_t Pankaj Raghav
2026-06-16 13:15 ` Christoph Hellwig
2026-06-11 11:40 ` [PATCH v6 2/3] xfs: add an allocation mode to xfs_alloc_file_space() Pankaj Raghav
2026-06-16 13:15 ` Christoph Hellwig
2026-06-11 11:40 ` [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES Pankaj Raghav
2026-06-16 13:31 ` Christoph Hellwig [this message]
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=ajFQPANpajmFuKpi@infradead.org \
--to=hch@infradead.org \
--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=kundan.kumar@samsung.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=lukas@herbolt.com \
--cc=p.raghav@samsung.com \
--cc=pankaj.raghav@linux.dev \
--cc=yi.zhang@huawei.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.