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 > > > >
