On 25/10/2024 11:35, Ritesh Harjani (IBM) wrote:
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?
FS can decide to split the mappings when it couldn't allocate a single
large mapping of the requested length. Could be due to -
- already allocated extent followed by EOF,
- already allocated extent followed by a hole
- already mapped extent followed by an extent of different type (e.g. written followed by unwritten or unwritten followed by written)
This is the sort of scenario which I am concerned with. This issue has
been discussed at length for XFS forcealign support for atomic writes.
So far, the user can atomic write a single FS block regardless of
whether the extent in which it would be part of is in written or
unwritten state.
Now the rule will be to write multiple FS blocks atomically, all blocks
need to be in same written or unwritten state.
This oddity at least needs to be documented.
Better yet would be to not have this restriction.
- delalloc (not delalloc since we invalidate respective page cache pages before doing DIO).
- fragmentation or ENOSPC - For ext4 bigalloc this will not happen since
we reserve the entire cluster. So we know there should be space. But I
am not sure how other filesystems might end up implementing this functionality.
Thanks,
John
