Here we are lifting the limitation of iomap to support entire iter->len- if (atomic && length != fs_block_size)Here you expect just one iter for an atomic write always.
+ if (atomic && length != iter->len)
return -EINVAL;
rather than just 1 fsblock.
In 6/6, you are saying that iomap does not allow an atomic write whichNo, it's not that. If FS does not provide a full mapping to iomap in
covers unwritten and written extents, right?
->iomap_begin then the writes will get split.
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 beSame as mentioned above. We can't have atomic writes to get split.
in unwritten state. So there is a difference in behavior in writing a
single FS block vs multiple FS blocks atomically.
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.