* Re: [PATCH v2 1/7] filemap: add helper to look up dirty folios in a range
2025-07-14 13:20 ` [PATCH v2 1/7] filemap: add helper to look up dirty folios in a range Brian Foster
@ 2025-07-14 13:19 ` Christoph Hellwig
0 siblings, 0 replies; 16+ messages in thread
From: Christoph Hellwig @ 2025-07-14 13:19 UTC (permalink / raw)
To: Brian Foster; +Cc: linux-fsdevel, linux-xfs, linux-mm, hch, djwong, willy
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
(although for this code you probably really want an ACK from willy and
not me to be safe :))
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 2/7] iomap: move pos+len BUG_ON() to after folio lookup
2025-07-14 13:20 ` [PATCH v2 2/7] iomap: move pos+len BUG_ON() to after folio lookup Brian Foster
@ 2025-07-14 13:20 ` Christoph Hellwig
2025-07-14 13:42 ` Brian Foster
0 siblings, 1 reply; 16+ messages in thread
From: Christoph Hellwig @ 2025-07-14 13:20 UTC (permalink / raw)
To: Brian Foster; +Cc: linux-fsdevel, linux-xfs, linux-mm, hch, djwong, willy
On Mon, Jul 14, 2025 at 09:20:54AM -0400, Brian Foster wrote:
> The bug checks at the top of iomap_write_begin() assume the pos/len
> reflect exactly the next range to process. This may no longer be the
> case once the get folio path is able to process a folio batch from
> the filesystem. Move the check a bit further down after the folio
> lookup and range trim to verify everything lines up with the current
> iomap.
The subject line is wrong now that the checks are removed entirely.
The patch itself looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 3/7] iomap: optional zero range dirty folio processing
2025-07-14 13:20 ` [PATCH v2 3/7] iomap: optional zero range dirty folio processing Brian Foster
@ 2025-07-14 13:20 ` Christoph Hellwig
0 siblings, 0 replies; 16+ messages in thread
From: Christoph Hellwig @ 2025-07-14 13:20 UTC (permalink / raw)
To: Brian Foster; +Cc: linux-fsdevel, linux-xfs, linux-mm, hch, djwong, willy
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v2 0/7] iomap: zero range folio batch support
@ 2025-07-14 13:20 Brian Foster
2025-07-14 13:20 ` [PATCH v2 1/7] filemap: add helper to look up dirty folios in a range Brian Foster
` (6 more replies)
0 siblings, 7 replies; 16+ messages in thread
From: Brian Foster @ 2025-07-14 13:20 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-xfs, linux-mm, hch, djwong, willy
Hi all,
Quick update.. This series was held up by testing work on my end. I
don't have the custom test to go along with patch 7 yet, but hch was
asking for updates, I have vacation looming, and realistically I wasn't
going to get to that beforehand. So I'm posting v2 without the
additional test and reviewers can decide if/how to proceed in the
meantime. Either way, I'll pick up where this leaves off.
Zero range is still obviously functionally testable. We just don't yet
have the enhanced coverage I was hoping for via the errortag knobs.
There are also a couple small fstests failures related to to tests that
explicitly expect unwritten extents in cases where this now decides to
perform zeroing (generic/009, xfs/242). I don't consider these
functional regressions, but the tests need to be fixed up to accommodate
behavior. Again, I'll get back to this stuff either way, it's just going
to be a couple weeks or so at least at this point. Thanks.
Brian
--- Original cover letter ---
Hi all,
Here's a first real v1 of folio batch support for iomap. This initially
only targets zero range, the use case being zeroing of dirty folios over
unwritten mappings. There is potential to support other operations in
the future: iomap seek data/hole has similar raciness issues as zero
range, the prospect of using this for buffered write has been raised for
granular locking purposes, etc.
The one major caveat with this zero range implementation is that it
doesn't look at iomap_folio_state to determine whether to zero a
sub-folio portion of the folio. Instead it just relies on whether the
folio was dirty or not. This means that spurious zeroing of unwritten
ranges is possible if a folio is dirty but the target range includes a
subrange that is not.
The reasoning is that this is essentially a complexity tradeoff. The
current use cases for iomap_zero_range() are limited mostly to partial
block zeroing scenarios. It's relatively harmless to zero an unwritten
block (i.e. not a correctness issue), and this is something that
filesystems have done in the past without much notice or issue. The
advantage is less code and this makes it a little easier to use a
filemap lookup function for the batch rather than open coding more logic
in iomap. That said, this can probably be enhanced to look at ifs in the
future if the use case expands and/or other operations justify it.
WRT testing, I've tested with and without a local hack to redirect
fallocate zero range calls to iomap_zero_range() in XFS. This helps test
beyond the partial block/folio use case, i.e. to cover boundary
conditions like full folio batch handling, etc. I recently added patch 7
in spirit of that, which turns this logic into an XFS errortag. Further
comments on that are inline with patch 7.
Thoughts, reviews, flames appreciated.
Brian
v2:
- Move filemap patch to top. Add some comments and drop export.
- Drop unnecessary BUG_ON()s from iomap_write_begin() instead of moving.
- Added folio mapping check to batch codepath, improved comments.
v1: https://lore.kernel.org/linux-fsdevel/20250605173357.579720-1-bfoster@redhat.com/
- Dropped most prep patches from previous version (merged separately).
- Reworked dirty folio lookup to use find_get_entry() loop (new patch
for filemap helper).
- Misc. bug fixes, code cleanups, comments, etc.
- Added (RFC) prospective patch for wider zero range test coverage.
RFCv2: https://lore.kernel.org/linux-fsdevel/20241213150528.1003662-1-bfoster@redhat.com/
- Port onto incremental advance, drop patch 1 from RFCv1.
- Moved batch into iomap_iter, dynamically allocate and drop flag.
- Tweak XFS patch to always trim zero range on EOF boundary.
RFCv1: https://lore.kernel.org/linux-fsdevel/20241119154656.774395-1-bfoster@redhat.com/
Brian Foster (7):
filemap: add helper to look up dirty folios in a range
iomap: move pos+len BUG_ON() to after folio lookup
iomap: optional zero range dirty folio processing
xfs: always trim mapping to requested range for zero range
xfs: fill dirty folios on zero range of unwritten mappings
iomap: remove old partial eof zeroing optimization
xfs: error tag to force zeroing on debug kernels
fs/iomap/buffered-io.c | 116 +++++++++++++++++++++++++----------
fs/iomap/iter.c | 6 ++
fs/xfs/libxfs/xfs_errortag.h | 4 +-
fs/xfs/xfs_error.c | 3 +
fs/xfs/xfs_file.c | 21 +++++--
fs/xfs/xfs_iomap.c | 38 +++++++++---
include/linux/iomap.h | 4 ++
include/linux/pagemap.h | 2 +
mm/filemap.c | 58 ++++++++++++++++++
9 files changed, 205 insertions(+), 47 deletions(-)
--
2.50.0
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v2 1/7] filemap: add helper to look up dirty folios in a range
2025-07-14 13:20 [PATCH v2 0/7] iomap: zero range folio batch support Brian Foster
@ 2025-07-14 13:20 ` Brian Foster
2025-07-14 13:19 ` Christoph Hellwig
2025-07-14 13:20 ` [PATCH v2 2/7] iomap: move pos+len BUG_ON() to after folio lookup Brian Foster
` (5 subsequent siblings)
6 siblings, 1 reply; 16+ messages in thread
From: Brian Foster @ 2025-07-14 13:20 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-xfs, linux-mm, hch, djwong, willy
Add a new filemap_get_folios_dirty() helper to look up existing dirty
folios in a range and add them to a folio_batch. This is to support
optimization of certain iomap operations that only care about dirty
folios in a target range. For example, zero range only zeroes the subset
of dirty pages over unwritten mappings, seek hole/data may use similar
logic in the future, etc.
Note that the helper is intended for use under internal fs locks.
Therefore it trylocks folios in order to filter out clean folios.
This loosely follows the logic from filemap_range_has_writeback().
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
include/linux/pagemap.h | 2 ++
mm/filemap.c | 58 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 60 insertions(+)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index e63fbfbd5b0f..fb83ddf26621 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -941,6 +941,8 @@ unsigned filemap_get_folios_contig(struct address_space *mapping,
pgoff_t *start, pgoff_t end, struct folio_batch *fbatch);
unsigned filemap_get_folios_tag(struct address_space *mapping, pgoff_t *start,
pgoff_t end, xa_mark_t tag, struct folio_batch *fbatch);
+unsigned filemap_get_folios_dirty(struct address_space *mapping,
+ pgoff_t *start, pgoff_t end, struct folio_batch *fbatch);
/*
* Returns locked page at given index in given cache, creating it if needed.
diff --git a/mm/filemap.c b/mm/filemap.c
index bada249b9fb7..2171b7f689b0 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2334,6 +2334,64 @@ unsigned filemap_get_folios_tag(struct address_space *mapping, pgoff_t *start,
}
EXPORT_SYMBOL(filemap_get_folios_tag);
+/**
+ * filemap_get_folios_dirty - Get a batch of dirty folios
+ * @mapping: The address_space to search
+ * @start: The starting folio index
+ * @end: The final folio index (inclusive)
+ * @fbatch: The batch to fill
+ *
+ * filemap_get_folios_dirty() works exactly like filemap_get_folios(), except
+ * the returned folios are presumed to be dirty or undergoing writeback. Dirty
+ * state is presumed because we don't block on folio lock nor want to miss
+ * folios. Callers that need to can recheck state upon locking the folio.
+ *
+ * This may not return all dirty folios if the batch gets filled up.
+ *
+ * Return: The number of folios found.
+ * Also update @start to be positioned for traversal of the next folio.
+ */
+unsigned filemap_get_folios_dirty(struct address_space *mapping, pgoff_t *start,
+ pgoff_t end, struct folio_batch *fbatch)
+{
+ XA_STATE(xas, &mapping->i_pages, *start);
+ struct folio *folio;
+
+ rcu_read_lock();
+ while ((folio = find_get_entry(&xas, end, XA_PRESENT)) != NULL) {
+ if (xa_is_value(folio))
+ continue;
+ if (folio_trylock(folio)) {
+ bool clean = !folio_test_dirty(folio) &&
+ !folio_test_writeback(folio);
+ folio_unlock(folio);
+ if (clean) {
+ folio_put(folio);
+ continue;
+ }
+ }
+ if (!folio_batch_add(fbatch, folio)) {
+ unsigned long nr = folio_nr_pages(folio);
+ *start = folio->index + nr;
+ goto out;
+ }
+ }
+ /*
+ * We come here when there is no folio beyond @end. We take care to not
+ * overflow the index @start as it confuses some of the callers. This
+ * breaks the iteration when there is a folio at index -1 but that is
+ * already broke anyway.
+ */
+ if (end == (pgoff_t)-1)
+ *start = (pgoff_t)-1;
+ else
+ *start = end + 1;
+out:
+ rcu_read_unlock();
+
+ return folio_batch_count(fbatch);
+}
+
/*
* CD/DVDs are error prone. When a medium error occurs, the driver may fail
* a _large_ part of the i/o request. Imagine the worst scenario:
--
2.50.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v2 2/7] iomap: move pos+len BUG_ON() to after folio lookup
2025-07-14 13:20 [PATCH v2 0/7] iomap: zero range folio batch support Brian Foster
2025-07-14 13:20 ` [PATCH v2 1/7] filemap: add helper to look up dirty folios in a range Brian Foster
@ 2025-07-14 13:20 ` Brian Foster
2025-07-14 13:20 ` Christoph Hellwig
2025-07-14 13:20 ` [PATCH v2 3/7] iomap: optional zero range dirty folio processing Brian Foster
` (4 subsequent siblings)
6 siblings, 1 reply; 16+ messages in thread
From: Brian Foster @ 2025-07-14 13:20 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-xfs, linux-mm, hch, djwong, willy
The bug checks at the top of iomap_write_begin() assume the pos/len
reflect exactly the next range to process. This may no longer be the
case once the get folio path is able to process a folio batch from
the filesystem. Move the check a bit further down after the folio
lookup and range trim to verify everything lines up with the current
iomap.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/iomap/buffered-io.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 3729391a18f3..38da2fa6e6b0 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -805,15 +805,12 @@ static int iomap_write_begin(struct iomap_iter *iter, struct folio **foliop,
{
const struct iomap_folio_ops *folio_ops = iter->iomap.folio_ops;
const struct iomap *srcmap = iomap_iter_srcmap(iter);
- loff_t pos = iter->pos;
+ loff_t pos;
u64 len = min_t(u64, SIZE_MAX, iomap_length(iter));
struct folio *folio;
int status = 0;
len = min_not_zero(len, *plen);
- BUG_ON(pos + len > iter->iomap.offset + iter->iomap.length);
- if (srcmap != &iter->iomap)
- BUG_ON(pos + len > srcmap->offset + srcmap->length);
if (fatal_signal_pending(current))
return -EINTR;
--
2.50.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v2 3/7] iomap: optional zero range dirty folio processing
2025-07-14 13:20 [PATCH v2 0/7] iomap: zero range folio batch support Brian Foster
2025-07-14 13:20 ` [PATCH v2 1/7] filemap: add helper to look up dirty folios in a range Brian Foster
2025-07-14 13:20 ` [PATCH v2 2/7] iomap: move pos+len BUG_ON() to after folio lookup Brian Foster
@ 2025-07-14 13:20 ` Brian Foster
2025-07-14 13:20 ` Christoph Hellwig
2025-07-14 13:20 ` [PATCH v2 4/7] xfs: always trim mapping to requested range for zero range Brian Foster
` (3 subsequent siblings)
6 siblings, 1 reply; 16+ messages in thread
From: Brian Foster @ 2025-07-14 13:20 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-xfs, linux-mm, hch, djwong, willy
The only way zero range can currently process unwritten mappings
with dirty pagecache is to check whether the range is dirty before
mapping lookup and then flush when at least one underlying mapping
is unwritten. This ordering is required to prevent iomap lookup from
racing with folio writeback and reclaim.
Since zero range can skip ranges of unwritten mappings that are
clean in cache, this operation can be improved by allowing the
filesystem to provide a set of dirty folios that require zeroing. In
turn, rather than flush or iterate file offsets, zero range can
iterate on folios in the batch and advance over clean or uncached
ranges in between.
Add a folio_batch in struct iomap and provide a helper for fs' to
populate the batch at lookup time. Update the folio lookup path to
return the next folio in the batch, if provided, and advance the
iter if the folio starts beyond the current offset.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/iomap/buffered-io.c | 89 +++++++++++++++++++++++++++++++++++++++---
fs/iomap/iter.c | 6 +++
include/linux/iomap.h | 4 ++
3 files changed, 94 insertions(+), 5 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 38da2fa6e6b0..194e3cc0857f 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -750,6 +750,28 @@ static struct folio *__iomap_get_folio(struct iomap_iter *iter, size_t len)
if (!mapping_large_folio_support(iter->inode->i_mapping))
len = min_t(size_t, len, PAGE_SIZE - offset_in_page(pos));
+ if (iter->fbatch) {
+ struct folio *folio = folio_batch_next(iter->fbatch);
+
+ if (!folio)
+ return NULL;
+
+ /*
+ * The folio mapping generally shouldn't have changed based on
+ * fs locks, but be consistent with filemap lookup and retry
+ * the iter if it does.
+ */
+ folio_lock(folio);
+ if (unlikely(folio->mapping != iter->inode->i_mapping)) {
+ iter->iomap.flags |= IOMAP_F_STALE;
+ folio_unlock(folio);
+ return NULL;
+ }
+
+ folio_get(folio);
+ return folio;
+ }
+
if (folio_ops && folio_ops->get_folio)
return folio_ops->get_folio(iter, pos, len);
else
@@ -811,6 +833,8 @@ static int iomap_write_begin(struct iomap_iter *iter, struct folio **foliop,
int status = 0;
len = min_not_zero(len, *plen);
+ *foliop = NULL;
+ *plen = 0;
if (fatal_signal_pending(current))
return -EINTR;
@@ -819,6 +843,15 @@ static int iomap_write_begin(struct iomap_iter *iter, struct folio **foliop,
if (IS_ERR(folio))
return PTR_ERR(folio);
+ /*
+ * No folio means we're done with a batch. We still have range to
+ * process so return and let the caller iterate and refill the batch.
+ */
+ if (!folio) {
+ WARN_ON_ONCE(!iter->fbatch);
+ return 0;
+ }
+
/*
* Now we have a locked folio, before we do anything with it we need to
* check that the iomap we have cached is not stale. The inode extent
@@ -839,6 +872,21 @@ static int iomap_write_begin(struct iomap_iter *iter, struct folio **foliop,
}
}
+ /*
+ * The folios in a batch may not be contiguous. If we've skipped
+ * forward, advance the iter to the pos of the current folio. If the
+ * folio starts beyond the end of the mapping, it may have been trimmed
+ * since the lookup for whatever reason. Return a NULL folio to
+ * terminate the op.
+ */
+ if (folio_pos(folio) > iter->pos) {
+ len = min_t(u64, folio_pos(folio) - iter->pos,
+ iomap_length(iter));
+ status = iomap_iter_advance(iter, &len);
+ if (status || !len)
+ goto out_unlock;
+ }
+
pos = iomap_trim_folio_range(iter, folio, poffset, &len);
if (srcmap->type == IOMAP_INLINE)
@@ -1377,6 +1425,12 @@ static int iomap_zero_iter(struct iomap_iter *iter, bool *did_zero)
if (iter->iomap.flags & IOMAP_F_STALE)
break;
+ /* a NULL folio means we're done with a folio batch */
+ if (!folio) {
+ status = iomap_iter_advance_full(iter);
+ break;
+ }
+
/* warn about zeroing folios beyond eof that won't write back */
WARN_ON_ONCE(folio_pos(folio) > iter->inode->i_size);
@@ -1398,6 +1452,26 @@ static int iomap_zero_iter(struct iomap_iter *iter, bool *did_zero)
return status;
}
+loff_t
+iomap_fill_dirty_folios(
+ struct iomap_iter *iter,
+ loff_t offset,
+ loff_t length)
+{
+ struct address_space *mapping = iter->inode->i_mapping;
+ pgoff_t start = offset >> PAGE_SHIFT;
+ pgoff_t end = (offset + length - 1) >> PAGE_SHIFT;
+
+ iter->fbatch = kmalloc(sizeof(struct folio_batch), GFP_KERNEL);
+ if (!iter->fbatch)
+ return offset + length;
+ folio_batch_init(iter->fbatch);
+
+ filemap_get_folios_dirty(mapping, &start, end, iter->fbatch);
+ return (start << PAGE_SHIFT);
+}
+EXPORT_SYMBOL_GPL(iomap_fill_dirty_folios);
+
int
iomap_zero_range(struct inode *inode, loff_t pos, loff_t len, bool *did_zero,
const struct iomap_ops *ops, void *private)
@@ -1426,7 +1500,7 @@ iomap_zero_range(struct inode *inode, loff_t pos, loff_t len, bool *did_zero,
* flushing on partial eof zeroing, special case it to zero the
* unaligned start portion if already dirty in pagecache.
*/
- if (off &&
+ if (!iter.fbatch && off &&
filemap_range_needs_writeback(mapping, pos, pos + plen - 1)) {
iter.len = plen;
while ((ret = iomap_iter(&iter, ops)) > 0)
@@ -1442,13 +1516,18 @@ iomap_zero_range(struct inode *inode, loff_t pos, loff_t len, bool *did_zero,
* if dirty and the fs returns a mapping that might convert on
* writeback.
*/
- range_dirty = filemap_range_needs_writeback(inode->i_mapping,
- iter.pos, iter.pos + iter.len - 1);
+ range_dirty = filemap_range_needs_writeback(mapping, iter.pos,
+ iter.pos + iter.len - 1);
while ((ret = iomap_iter(&iter, ops)) > 0) {
const struct iomap *srcmap = iomap_iter_srcmap(&iter);
- if (srcmap->type == IOMAP_HOLE ||
- srcmap->type == IOMAP_UNWRITTEN) {
+ if (WARN_ON_ONCE(iter.fbatch &&
+ srcmap->type != IOMAP_UNWRITTEN))
+ return -EIO;
+
+ if (!iter.fbatch &&
+ (srcmap->type == IOMAP_HOLE ||
+ srcmap->type == IOMAP_UNWRITTEN)) {
s64 status;
if (range_dirty) {
diff --git a/fs/iomap/iter.c b/fs/iomap/iter.c
index 6ffc6a7b9ba5..89bd5951a6fd 100644
--- a/fs/iomap/iter.c
+++ b/fs/iomap/iter.c
@@ -9,6 +9,12 @@
static inline void iomap_iter_reset_iomap(struct iomap_iter *iter)
{
+ if (iter->fbatch) {
+ folio_batch_release(iter->fbatch);
+ kfree(iter->fbatch);
+ iter->fbatch = NULL;
+ }
+
iter->status = 0;
memset(&iter->iomap, 0, sizeof(iter->iomap));
memset(&iter->srcmap, 0, sizeof(iter->srcmap));
diff --git a/include/linux/iomap.h b/include/linux/iomap.h
index 522644d62f30..0b9b460b2873 100644
--- a/include/linux/iomap.h
+++ b/include/linux/iomap.h
@@ -9,6 +9,7 @@
#include <linux/types.h>
#include <linux/mm_types.h>
#include <linux/blkdev.h>
+#include <linux/pagevec.h>
struct address_space;
struct fiemap_extent_info;
@@ -239,6 +240,7 @@ struct iomap_iter {
unsigned flags;
struct iomap iomap;
struct iomap srcmap;
+ struct folio_batch *fbatch;
void *private;
};
@@ -345,6 +347,8 @@ void iomap_invalidate_folio(struct folio *folio, size_t offset, size_t len);
bool iomap_dirty_folio(struct address_space *mapping, struct folio *folio);
int iomap_file_unshare(struct inode *inode, loff_t pos, loff_t len,
const struct iomap_ops *ops);
+loff_t iomap_fill_dirty_folios(struct iomap_iter *iter, loff_t offset,
+ loff_t length);
int iomap_zero_range(struct inode *inode, loff_t pos, loff_t len,
bool *did_zero, const struct iomap_ops *ops, void *private);
int iomap_truncate_page(struct inode *inode, loff_t pos, bool *did_zero,
--
2.50.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v2 4/7] xfs: always trim mapping to requested range for zero range
2025-07-14 13:20 [PATCH v2 0/7] iomap: zero range folio batch support Brian Foster
` (2 preceding siblings ...)
2025-07-14 13:20 ` [PATCH v2 3/7] iomap: optional zero range dirty folio processing Brian Foster
@ 2025-07-14 13:20 ` Brian Foster
2025-07-14 13:20 ` [PATCH v2 5/7] xfs: fill dirty folios on zero range of unwritten mappings Brian Foster
` (2 subsequent siblings)
6 siblings, 0 replies; 16+ messages in thread
From: Brian Foster @ 2025-07-14 13:20 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-xfs, linux-mm, hch, djwong, willy
Refactor and tweak the IOMAP_ZERO logic in preparation to support
filling the folio batch for unwritten mappings. Drop the superfluous
imap offset check since the hole case has already been filtered out.
Split the the delalloc case handling into a sub-branch, and always
trim the imap to the requested offset/count so it can be more easily
used to bound the range to lookup in pagecache.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
---
fs/xfs/xfs_iomap.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index ff05e6b1b0bb..b5cf5bc6308d 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1756,21 +1756,20 @@ xfs_buffered_write_iomap_begin(
}
/*
- * For zeroing, trim a delalloc extent that extends beyond the EOF
- * block. If it starts beyond the EOF block, convert it to an
+ * For zeroing, trim extents that extend beyond the EOF block. If a
+ * delalloc extent starts beyond the EOF block, convert it to an
* unwritten extent.
*/
- if ((flags & IOMAP_ZERO) && imap.br_startoff <= offset_fsb &&
- isnullstartblock(imap.br_startblock)) {
+ if (flags & IOMAP_ZERO) {
xfs_fileoff_t eof_fsb = XFS_B_TO_FSB(mp, XFS_ISIZE(ip));
- if (offset_fsb >= eof_fsb)
+ if (isnullstartblock(imap.br_startblock) &&
+ offset_fsb >= eof_fsb)
goto convert_delay;
- if (end_fsb > eof_fsb) {
+ if (offset_fsb < eof_fsb && end_fsb > eof_fsb)
end_fsb = eof_fsb;
- xfs_trim_extent(&imap, offset_fsb,
- end_fsb - offset_fsb);
- }
+
+ xfs_trim_extent(&imap, offset_fsb, end_fsb - offset_fsb);
}
/*
--
2.50.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v2 5/7] xfs: fill dirty folios on zero range of unwritten mappings
2025-07-14 13:20 [PATCH v2 0/7] iomap: zero range folio batch support Brian Foster
` (3 preceding siblings ...)
2025-07-14 13:20 ` [PATCH v2 4/7] xfs: always trim mapping to requested range for zero range Brian Foster
@ 2025-07-14 13:20 ` Brian Foster
2025-07-14 13:21 ` Christoph Hellwig
2025-07-14 13:20 ` [PATCH v2 6/7] iomap: remove old partial eof zeroing optimization Brian Foster
2025-07-14 13:20 ` [PATCH v2 7/7] xfs: error tag to force zeroing on debug kernels Brian Foster
6 siblings, 1 reply; 16+ messages in thread
From: Brian Foster @ 2025-07-14 13:20 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-xfs, linux-mm, hch, djwong, willy
Use the iomap folio batch mechanism to select folios to zero on zero
range of unwritten mappings. Trim the resulting mapping if the batch
is filled (unlikely for current use cases) to distinguish between a
range to skip and one that requires another iteration due to a full
batch.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/xfs/xfs_iomap.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index b5cf5bc6308d..63054f7ead0e 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1691,6 +1691,8 @@ xfs_buffered_write_iomap_begin(
struct iomap *iomap,
struct iomap *srcmap)
{
+ struct iomap_iter *iter = container_of(iomap, struct iomap_iter,
+ iomap);
struct xfs_inode *ip = XFS_I(inode);
struct xfs_mount *mp = ip->i_mount;
xfs_fileoff_t offset_fsb = XFS_B_TO_FSBT(mp, offset);
@@ -1762,6 +1764,7 @@ xfs_buffered_write_iomap_begin(
*/
if (flags & IOMAP_ZERO) {
xfs_fileoff_t eof_fsb = XFS_B_TO_FSB(mp, XFS_ISIZE(ip));
+ u64 end;
if (isnullstartblock(imap.br_startblock) &&
offset_fsb >= eof_fsb)
@@ -1769,6 +1772,26 @@ xfs_buffered_write_iomap_begin(
if (offset_fsb < eof_fsb && end_fsb > eof_fsb)
end_fsb = eof_fsb;
+ /*
+ * Look up dirty folios for unwritten mappings within EOF.
+ * Providing this bypasses the flush iomap uses to trigger
+ * extent conversion when unwritten mappings have dirty
+ * pagecache in need of zeroing.
+ *
+ * Trim the mapping to the end pos of the lookup, which in turn
+ * was trimmed to the end of the batch if it became full before
+ * the end of the mapping.
+ */
+ if (imap.br_state == XFS_EXT_UNWRITTEN &&
+ offset_fsb < eof_fsb) {
+ loff_t len = min(count,
+ XFS_FSB_TO_B(mp, imap.br_blockcount));
+
+ end = iomap_fill_dirty_folios(iter, offset, len);
+ end_fsb = min_t(xfs_fileoff_t, end_fsb,
+ XFS_B_TO_FSB(mp, end));
+ }
+
xfs_trim_extent(&imap, offset_fsb, end_fsb - offset_fsb);
}
--
2.50.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v2 6/7] iomap: remove old partial eof zeroing optimization
2025-07-14 13:20 [PATCH v2 0/7] iomap: zero range folio batch support Brian Foster
` (4 preceding siblings ...)
2025-07-14 13:20 ` [PATCH v2 5/7] xfs: fill dirty folios on zero range of unwritten mappings Brian Foster
@ 2025-07-14 13:20 ` Brian Foster
2025-07-14 13:20 ` [PATCH v2 7/7] xfs: error tag to force zeroing on debug kernels Brian Foster
6 siblings, 0 replies; 16+ messages in thread
From: Brian Foster @ 2025-07-14 13:20 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-xfs, linux-mm, hch, djwong, willy
iomap_zero_range() optimizes the partial eof block zeroing use case
by force zeroing if the mapping is dirty. This is to avoid frequent
flushing on file extending workloads, which hurts performance.
Now that the folio batch mechanism provides a more generic solution
and is used by the only real zero range user (XFS), this isolated
optimization is no longer needed. Remove the unnecessary code and
let callers use the folio batch or fall back to flushing by default.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
fs/iomap/buffered-io.c | 24 ------------------------
1 file changed, 24 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 194e3cc0857f..d2bbed692c06 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -1484,33 +1484,9 @@ iomap_zero_range(struct inode *inode, loff_t pos, loff_t len, bool *did_zero,
.private = private,
};
struct address_space *mapping = inode->i_mapping;
- unsigned int blocksize = i_blocksize(inode);
- unsigned int off = pos & (blocksize - 1);
- loff_t plen = min_t(loff_t, len, blocksize - off);
int ret;
bool range_dirty;
- /*
- * Zero range can skip mappings that are zero on disk so long as
- * pagecache is clean. If pagecache was dirty prior to zero range, the
- * mapping converts on writeback completion and so must be zeroed.
- *
- * The simplest way to deal with this across a range is to flush
- * pagecache and process the updated mappings. To avoid excessive
- * flushing on partial eof zeroing, special case it to zero the
- * unaligned start portion if already dirty in pagecache.
- */
- if (!iter.fbatch && off &&
- filemap_range_needs_writeback(mapping, pos, pos + plen - 1)) {
- iter.len = plen;
- while ((ret = iomap_iter(&iter, ops)) > 0)
- iter.status = iomap_zero_iter(&iter, did_zero);
-
- iter.len = len - (iter.pos - pos);
- if (ret || !iter.len)
- return ret;
- }
-
/*
* To avoid an unconditional flush, check pagecache state and only flush
* if dirty and the fs returns a mapping that might convert on
--
2.50.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v2 7/7] xfs: error tag to force zeroing on debug kernels
2025-07-14 13:20 [PATCH v2 0/7] iomap: zero range folio batch support Brian Foster
` (5 preceding siblings ...)
2025-07-14 13:20 ` [PATCH v2 6/7] iomap: remove old partial eof zeroing optimization Brian Foster
@ 2025-07-14 13:20 ` Brian Foster
2025-07-14 13:23 ` Christoph Hellwig
6 siblings, 1 reply; 16+ messages in thread
From: Brian Foster @ 2025-07-14 13:20 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-xfs, linux-mm, hch, djwong, willy
iomap_zero_range() has to cover various corner cases that are
difficult to test on production kernels because it is used in fairly
limited use cases. For example, it is currently only used by XFS and
mostly only in partial block zeroing cases.
While it's possible to test most of these functional cases, we can
provide more robust test coverage by co-opting fallocate zero range
to invoke zeroing of the entire range instead of the more efficient
block punch/allocate sequence. Add an errortag to occasionally
invoke forced zeroing.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/xfs/libxfs/xfs_errortag.h | 4 +++-
fs/xfs/xfs_error.c | 3 +++
fs/xfs/xfs_file.c | 21 +++++++++++++++------
3 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_errortag.h b/fs/xfs/libxfs/xfs_errortag.h
index a53c5d40e084..33ca3fc2ca88 100644
--- a/fs/xfs/libxfs/xfs_errortag.h
+++ b/fs/xfs/libxfs/xfs_errortag.h
@@ -65,7 +65,8 @@
#define XFS_ERRTAG_WRITE_DELAY_MS 43
#define XFS_ERRTAG_EXCHMAPS_FINISH_ONE 44
#define XFS_ERRTAG_METAFILE_RESV_CRITICAL 45
-#define XFS_ERRTAG_MAX 46
+#define XFS_ERRTAG_FORCE_ZERO_RANGE 46
+#define XFS_ERRTAG_MAX 47
/*
* Random factors for above tags, 1 means always, 2 means 1/2 time, etc.
@@ -115,5 +116,6 @@
#define XFS_RANDOM_WRITE_DELAY_MS 3000
#define XFS_RANDOM_EXCHMAPS_FINISH_ONE 1
#define XFS_RANDOM_METAFILE_RESV_CRITICAL 4
+#define XFS_RANDOM_FORCE_ZERO_RANGE 4
#endif /* __XFS_ERRORTAG_H_ */
diff --git a/fs/xfs/xfs_error.c b/fs/xfs/xfs_error.c
index dbd87e137694..00c0c391c329 100644
--- a/fs/xfs/xfs_error.c
+++ b/fs/xfs/xfs_error.c
@@ -64,6 +64,7 @@ static unsigned int xfs_errortag_random_default[] = {
XFS_RANDOM_WRITE_DELAY_MS,
XFS_RANDOM_EXCHMAPS_FINISH_ONE,
XFS_RANDOM_METAFILE_RESV_CRITICAL,
+ XFS_RANDOM_FORCE_ZERO_RANGE,
};
struct xfs_errortag_attr {
@@ -183,6 +184,7 @@ XFS_ERRORTAG_ATTR_RW(wb_delay_ms, XFS_ERRTAG_WB_DELAY_MS);
XFS_ERRORTAG_ATTR_RW(write_delay_ms, XFS_ERRTAG_WRITE_DELAY_MS);
XFS_ERRORTAG_ATTR_RW(exchmaps_finish_one, XFS_ERRTAG_EXCHMAPS_FINISH_ONE);
XFS_ERRORTAG_ATTR_RW(metafile_resv_crit, XFS_ERRTAG_METAFILE_RESV_CRITICAL);
+XFS_ERRORTAG_ATTR_RW(force_zero_range, XFS_ERRTAG_FORCE_ZERO_RANGE);
static struct attribute *xfs_errortag_attrs[] = {
XFS_ERRORTAG_ATTR_LIST(noerror),
@@ -230,6 +232,7 @@ static struct attribute *xfs_errortag_attrs[] = {
XFS_ERRORTAG_ATTR_LIST(write_delay_ms),
XFS_ERRORTAG_ATTR_LIST(exchmaps_finish_one),
XFS_ERRORTAG_ATTR_LIST(metafile_resv_crit),
+ XFS_ERRORTAG_ATTR_LIST(force_zero_range),
NULL,
};
ATTRIBUTE_GROUPS(xfs_errortag);
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 0b41b18debf3..227ae8bcc217 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -27,6 +27,8 @@
#include "xfs_file.h"
#include "xfs_aops.h"
#include "xfs_zone_alloc.h"
+#include "xfs_error.h"
+#include "xfs_errortag.h"
#include <linux/dax.h>
#include <linux/falloc.h>
@@ -1269,13 +1271,20 @@ xfs_falloc_zero_range(
if (error)
return error;
- error = xfs_free_file_space(XFS_I(inode), offset, len, ac);
- if (error)
- return error;
+ /* randomly force zeroing to exercise zero range */
+ if (XFS_TEST_ERROR(false, XFS_I(inode)->i_mount,
+ XFS_ERRTAG_FORCE_ZERO_RANGE)) {
+ error = xfs_zero_range(XFS_I(inode), offset, len, ac, NULL);
+ } else {
+ error = xfs_free_file_space(XFS_I(inode), offset, len, ac);
+ if (error)
+ return error;
- len = round_up(offset + len, blksize) - round_down(offset, blksize);
- offset = round_down(offset, blksize);
- error = xfs_alloc_file_space(XFS_I(inode), offset, len);
+ len = round_up(offset + len, blksize) -
+ round_down(offset, blksize);
+ offset = round_down(offset, blksize);
+ error = xfs_alloc_file_space(XFS_I(inode), offset, len);
+ }
if (error)
return error;
return xfs_falloc_setsize(file, new_size);
--
2.50.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v2 5/7] xfs: fill dirty folios on zero range of unwritten mappings
2025-07-14 13:20 ` [PATCH v2 5/7] xfs: fill dirty folios on zero range of unwritten mappings Brian Foster
@ 2025-07-14 13:21 ` Christoph Hellwig
0 siblings, 0 replies; 16+ messages in thread
From: Christoph Hellwig @ 2025-07-14 13:21 UTC (permalink / raw)
To: Brian Foster; +Cc: linux-fsdevel, linux-xfs, linux-mm, hch, djwong, willy
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 7/7] xfs: error tag to force zeroing on debug kernels
2025-07-14 13:20 ` [PATCH v2 7/7] xfs: error tag to force zeroing on debug kernels Brian Foster
@ 2025-07-14 13:23 ` Christoph Hellwig
2025-07-14 13:42 ` Brian Foster
2025-07-14 14:12 ` Brian Foster
0 siblings, 2 replies; 16+ messages in thread
From: Christoph Hellwig @ 2025-07-14 13:23 UTC (permalink / raw)
To: Brian Foster; +Cc: linux-fsdevel, linux-xfs, linux-mm, hch, djwong, willy
On Mon, Jul 14, 2025 at 09:20:59AM -0400, Brian Foster wrote:
> - error = xfs_free_file_space(XFS_I(inode), offset, len, ac);
> - if (error)
> - return error;
> + /* randomly force zeroing to exercise zero range */
This comment feels very sparse for this somewhat confusing behavior.
Can you add a shortened version of the commit message here explaining
why this is useful?
Otherwise looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 2/7] iomap: move pos+len BUG_ON() to after folio lookup
2025-07-14 13:20 ` Christoph Hellwig
@ 2025-07-14 13:42 ` Brian Foster
0 siblings, 0 replies; 16+ messages in thread
From: Brian Foster @ 2025-07-14 13:42 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-fsdevel, linux-xfs, linux-mm, djwong, willy
On Mon, Jul 14, 2025 at 06:20:08AM -0700, Christoph Hellwig wrote:
> On Mon, Jul 14, 2025 at 09:20:54AM -0400, Brian Foster wrote:
> > The bug checks at the top of iomap_write_begin() assume the pos/len
> > reflect exactly the next range to process. This may no longer be the
> > case once the get folio path is able to process a folio batch from
> > the filesystem. Move the check a bit further down after the folio
> > lookup and range trim to verify everything lines up with the current
> > iomap.
>
> The subject line is wrong now that the checks are removed entirely.
>
Er yeah, I have to update the commit log description too.
Brian
> The patch itself looks good:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 7/7] xfs: error tag to force zeroing on debug kernels
2025-07-14 13:23 ` Christoph Hellwig
@ 2025-07-14 13:42 ` Brian Foster
2025-07-14 14:12 ` Brian Foster
1 sibling, 0 replies; 16+ messages in thread
From: Brian Foster @ 2025-07-14 13:42 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-fsdevel, linux-xfs, linux-mm, djwong, willy
On Mon, Jul 14, 2025 at 06:23:01AM -0700, Christoph Hellwig wrote:
> On Mon, Jul 14, 2025 at 09:20:59AM -0400, Brian Foster wrote:
> > - error = xfs_free_file_space(XFS_I(inode), offset, len, ac);
> > - if (error)
> > - return error;
> > + /* randomly force zeroing to exercise zero range */
>
> This comment feels very sparse for this somewhat confusing behavior.
> Can you add a shortened version of the commit message here explaining
> why this is useful?
>
Sure, will fix.
Brian
> Otherwise looks good:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 7/7] xfs: error tag to force zeroing on debug kernels
2025-07-14 13:23 ` Christoph Hellwig
2025-07-14 13:42 ` Brian Foster
@ 2025-07-14 14:12 ` Brian Foster
1 sibling, 0 replies; 16+ messages in thread
From: Brian Foster @ 2025-07-14 14:12 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-fsdevel, linux-xfs, linux-mm, djwong, willy
On Mon, Jul 14, 2025 at 06:23:01AM -0700, Christoph Hellwig wrote:
> On Mon, Jul 14, 2025 at 09:20:59AM -0400, Brian Foster wrote:
> > - error = xfs_free_file_space(XFS_I(inode), offset, len, ac);
> > - if (error)
> > - return error;
> > + /* randomly force zeroing to exercise zero range */
>
> This comment feels very sparse for this somewhat confusing behavior.
> Can you add a shortened version of the commit message here explaining
> why this is useful?
>
I replaced the comment with:
/*
* Zero range implements a full zeroing mechanism but is only used in
* limited situations. It is more efficient to allocate unwritten
* extents than to perform zeroing here, so use an errortag to randomly
* force zeroing on DEBUG kernels for added test coverage.
*/
Unless I hear further comments I'll post an update with this by the end
of the day.
Brian
> Otherwise looks good:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2025-07-14 14:09 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-14 13:20 [PATCH v2 0/7] iomap: zero range folio batch support Brian Foster
2025-07-14 13:20 ` [PATCH v2 1/7] filemap: add helper to look up dirty folios in a range Brian Foster
2025-07-14 13:19 ` Christoph Hellwig
2025-07-14 13:20 ` [PATCH v2 2/7] iomap: move pos+len BUG_ON() to after folio lookup Brian Foster
2025-07-14 13:20 ` Christoph Hellwig
2025-07-14 13:42 ` Brian Foster
2025-07-14 13:20 ` [PATCH v2 3/7] iomap: optional zero range dirty folio processing Brian Foster
2025-07-14 13:20 ` Christoph Hellwig
2025-07-14 13:20 ` [PATCH v2 4/7] xfs: always trim mapping to requested range for zero range Brian Foster
2025-07-14 13:20 ` [PATCH v2 5/7] xfs: fill dirty folios on zero range of unwritten mappings Brian Foster
2025-07-14 13:21 ` Christoph Hellwig
2025-07-14 13:20 ` [PATCH v2 6/7] iomap: remove old partial eof zeroing optimization Brian Foster
2025-07-14 13:20 ` [PATCH v2 7/7] xfs: error tag to force zeroing on debug kernels Brian Foster
2025-07-14 13:23 ` Christoph Hellwig
2025-07-14 13:42 ` Brian Foster
2025-07-14 14:12 ` Brian Foster
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).