On 25/10/2024 10:31, Ritesh Harjani (IBM) wrote:
- if (atomic && length != fs_block_size)
+ if (atomic && length != iter->len)
return -EINVAL;
Here you expect just one iter for an atomic write always.
Here we are lifting the limitation of iomap to support entire iter->len
rather than just 1 fsblock.
Sure
In 6/6, you are saying that iomap does not allow an atomic write which
covers unwritten and written extents, right?
No, it's not that. If FS does not provide a full mapping to iomap in
->iomap_begin then the writes will get split.
but why would it provide multiple mapping?
For atomic writes this
should not happen, hence the check in iomap above to return -EINVAL if
mapped length does not match iter->len.
But for writing a single fs block atomically, we don't mandate it to be
in unwritten state. So there is a difference in behavior in writing a
single FS block vs multiple FS blocks atomically.
Same as mentioned above. We can't have atomic writes to get split.
This patch is just lifting the restriction of iomap to allow more than
blocksize but the mapped length should still meet iter->len, as
otherwise the writes can get split.
Sure, I get this. But I wonder why would we be getting multiple
mappings? Why cannot the FS always provide a single mapping?
Thanks,
John
