That's what this patch does.So user will anyway will have to be made aware of not toThat's my least-preferred option.
attempt writes of fashion which can cause them such penalties.
As patch-6 mentions this is a base support for bs = ps systems for
enabling atomic writes using bigalloc. For now we return -EINVAL when we
can't allocate a continuous user requested mapping which means it won't
support operations of types 8k followed by 16k.
I think better would be reject atomic writes that cover unwritten
extents always - but that boat is about to sail...
For whatever reason if we couldn't allocate
a single contiguous region of requested size for atomic write, then we
reject the request always, isn't it. Or maybe I didn't understand your comment.
> > I think this maybe better option than waiting until ->iomap_begin().
If others prefer - we can maybe add such a check (e.g. ext4_dio_atomic_write_checks())
for atomic writes in ext4_dio_write_checks(), similar to how we detect
overwrites case to decide whether we need a read v/s write semaphore.
So this can check if the user has a partially allocated extent for the
user requested region and if yes, we can return -EINVAL from
ext4_dio_write_iter() itself.
This might also bring all atomic write constraints to be checked in one
place i.e. during ext4_file_write_iter() itself.