On 26/07/2024 18:13, Christoph Hellwig wrote:
On Fri, Jul 26, 2024 at 03:29:48PM +0100, John Garry wrote:
I have been considering another approach to solve this problem.
In this patch - as you know - we zero unwritten parts of a newly allocated
extent. This is so that when we later issue an atomic write, we would not
have the problem of unwritten extents and how the iomap iterator will
create multiple BIOs (which is not permitted).
How about an alternate approach like this:
- no sub-extent zeroing
- iomap iter is changed to allocate a single BIO for an atomic write in
first iteration
- each iomap extent iteration appends data to that same BIO
- when finished iterating, we submit the BIO
Obviously that will mean many changes to the iomap bio iterator, but is
quite self-contained.
Yes, I also suggested that during the zeroing fix discussion.
Maybe missed that. I did notice
https://lore.kernel.org/linux-xfs/ZmwJuiMHQ8qgkJDS@xxxxxxxxxxxxx, but
got a different impression of your idea there (to this one).
There
is generally no good reason to start a new direct I/O bio if the
write is contiguous on disk and only the state of the srcmap is different.
Sure, so we don't need to worry about partially-completed writes, if
that was a concern; and it would also mean dropping that unpleasant code
change in xfs_iomap_write_unwritten() where the start/count fsb were
being rounded out to the extent granule boundary.
This will also be a big win for COW / out of place overwrites.
