Re: [PATCH 1/4] iomap: Lift blocksize restriction on atomic writes

[John Garry]

On 22/01/2025 23:51, Dave Chinner wrote:
> > I did my own quick PoC to use CoW for misaligned blocks atomic writes
> > fallback.
> >
> > I am finding that the block allocator is often giving misaligned blocks wrt
> > atomic write length, like this:
> Of course - I'm pretty sure this needs force-align to ensure that
> the large allocated extent is aligned to file offset and hardware
> atomic write alignment constraints....
>
> > Since we are not considering forcealign ATM, can we still consider some
> > other alignment hint to the block allocator? It could be similar to how
> > stripe alignment is handled.
> Perhaps we should finish off the the remaining bits needed to make
> force-align work everywhere before going any further?

forcealign implementation is just about finished from my PoV, but needs 
more review.

However, there has been push back on that feature - 
https://lore.kernel.org/linux-xfs/20240923120715.GA13585@xxxxxx/

So we will try this PoC for the unaligned software-emulated fallback, 
see how it looks - especially in terms of performance - and go from there.

> > Some other thoughts:
> > - I am not sure what atomic write unit max we would now use.
> What statx exposes should be the size/alignment for hardware offload
> to take place (i.e. no change)

The user could get that from statx on the block device on which we are 
mounted, if that is not too inconvenient.

> , regardless of what the filesystem
> can do software offloads for. i.e. like statx->stx_blksize is the
> "preferred block size for efficient IO", the atomic write unit
> information is the "preferred atomic write size and alignment for
> efficient IO", not the maximum sizes supported...

It's already documented that an atomic write which exceeds the unit max 
will be rejected. I don't like the idea of relaxing the API to "an 
atomic which exceeds unit max may be rejected". Indeed, in that case, 
the user may still want to know the non-optimal unit max.

> > - Anything written back with CoW/exchange range will need FUA to ensure that
> > the write is fully persisted.
> I don't think so. The journal commit for the exchange range
> operation will issue a cache flush before the journal IO is
> submitted. that will make the new data stable before the first
> xchgrange transaction becomes stable.
>
> Hence we get the correct data/metadata ordering on stable storage
> simply by doing the exchange-range operation at data IO completion.
> This the same data/metadata ordering semantics that unwritten extent
> conversion is based on....

I am not sure if we will use exchange range, but we need such behavior 
(in terms of persistence) described for whatever we do.

Thanks,
John