Re: [PATCH v2 04/11] iomap: Support CoW-based atomic writes

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Feb 25, 2025 at 10:19:49AM +0000, John Garry wrote:
> On 24/02/2025 19:59, Darrick J. Wong wrote:
> > > + * ``IOMAP_ATOMIC_COW``: This write is being issued with torn-write
> > > +   protection based on CoW support.
> > I think using "COW" here results in a misnamed flag.  Consider:
> > 
> > "IOMAP_ATOMIC_SW:
> 
> ok, fine
> 
> > This write is being issued with torn-write protection
> > via a software fallback provided by the filesystem."
> 
> I'm not sure that we really need to even mention software fallback. Indeed,
> xfs could just use IOMAP_ATOMIC_SW always when the bdev does not support HW
> offload. Maybe I can mention that typically it can be used as a software
> fallback when HW offload is not possible.

Ok, a software mechanism then.

> > 
> > iomap itself doesn't care*how* the filesystem guarantees that the
> > direct write isn't torn, right?
> 
> Correct. iomap just ensures that for IOMAP_ATOMIC_HW we produce a single bio
> - that's the only check really.
> 
> > The fs' io completion handler has to
> > ensure that the mapping update(s) are either applied fully or discarded
> > fully.
> 
> right
> 
> > 
> > In theory if you had a bunch of physical space mapped to the same
> > file but with different unwritten states, you could gang together all
> > the unwritten extent conversions in a single transaction, which would
> > provide the necessary tearing prevention without the out of place write.
> > Nobody does that right now, but I think that's the only option for ext4.
> 
> ok, maybe. But ext4 still does have bigalloc or opportunity to support
> forcealign (to always use IOMAP_ATOMIC_HW for large untorn writes).

<nod>

--D

> Thanks,
> John
> 
> 
> 
>