Re: [PATCH v6 10/13] xfs: iomap COW-based atomic write support

From: John Garry
Date: Mon Mar 17 2025 - 04:54:44 EST



+ }
end_fsb = imap.br_startoff + imap.br_blockcount;
length = XFS_FSB_TO_B(mp, end_fsb) - offset;
}
- if (imap_needs_alloc(inode, flags, &imap, nimaps))
+ needs_alloc = imap_needs_alloc(inode, flags, &imap, nimaps);
+
+ if (flags & IOMAP_ATOMIC) {
+ error = -EAGAIN;
+ /*
+ * If we allocate less than what is required for the write
+ * then we may end up with multiple mappings, which means that
+ * REQ_ATOMIC-based cannot be used, so avoid this possibility.
+ */
+ if (needs_alloc && orig_end_fsb - offset_fsb > 1)
+ goto out_unlock;

I have a quick question here. Based on above check it looks like
allocation requests on a hole or the 1st time allocation (append writes)
for a given logical range will always be done using CoW fallback
mechanism, isn't it?

Right, but...


So that means HW based multi-fsblock atomic write
request will only happen for over writes (non-discontigous extent),
correct?

For an unwritten pre-allocated extent, we can use the REQ_ATOMIC method.

fallocate (without ZERO RANGE) would give a pre-allocated unwritten extent, and a write there would not technically be an overwrite.


Now, it's not always necessary that if we try to allocate an extent for
the given range, it results into discontiguous extents. e.g. say, if the
entire range being written to is a hole or append writes, then it might
just allocate a single unwritten extent which is valid for doing an
atomic write using HW/BIOs right?

Right

And it is valid to write using unwritten extent as long as we don't have
mixed mappings i.e. the entire range should either be unwritten or
written for the atomic write to be untorned, correct?


We can't write to discontiguous extents, and a mixed mapping would mean discontiguous extents.

And, as mentioned earlier, it is ok to use REQ_ATOMIC method on an unwritten extent.

I am guessing this is kept intentional?

Yes

Thanks,
John