Re: [PATCH v6 0/6] block/md/dm: set chunk_sectors from stacked dev stripe size

[Christoph Hellwig <hch@lst.de>]

On Fri, Jul 11, 2025 at 05:44:26PM +0900, Damien Le Moal wrote:
> On 7/11/25 5:09 PM, John Garry wrote:
> > This value in io_min is used to configure any atomic write limit for the
> > stacked device. The idea is that the atomic write unit max is a
> > power-of-2 factor of the stripe size, and the stripe size is available
> > in io_min.
> > 
> > Using io_min causes issues, as:
> > a. it may be mutated
> > b. the check for io_min being set for determining if we are dealing with
> > a striped device is hard to get right, as reported in [0].
> > 
> > This series now sets chunk_sectors limit to share stripe size.
> 
> Hmm... chunk_sectors for a zoned device is the zone size. So is this all safe
> if we are dealing with a zoned block device that also supports atomic writes ?

Btw, I wonder if it's time to decouple the zone size from the chunk
size eventually.  It seems like a nice little hack, but with things
like parity raid for zoned devices now showing up at least in academia,
and nvme devices reporting chunk sizes the overload might not be that
good any more.

> Not that I know of any such device, but better be safe, so maybe for now
> do not enable atomic write support on zoned devices ?

How would atomic writes make sense for zone devices?  Because all writes
up to the reported write pointer must be valid, there usual checks for
partial updates a lacking, so the only use would be to figure out if a
write got truncated.  At least for file systems we detects this using the
fs metadata that must be written on I/O completion anyway, so the only
user would be an application with some sort of speculative writes that
can't detect partial writes. Which sounds rather fringe and dangerous.

Now we should be able to implement the software atomic writes pretty
easily for zoned XFS, and funnily they might actually be slightly faster
than normal writes due to the transaction batching.  Now that we're
getting reasonable test coverage we should be able to give it a spin, but
I have a few too many things on my plate at the moment.