Re: [PATCH RFC 1/2] block: add BLK_FEAT_ATOMIC_WRITE_MULTI

[Daniel Gomez <da.gomez@kernel.org>]

On 2026-11-03T11:38:49+02:00, Arthur Simchaev <arthur.simchaev@sandisk.com> wrote:
> On Tue, Sep 29, 2026 at 01:17:11PM +0200, Daniel Gomez wrote:
> [...]
> > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> > index d003a9d2d1f6c..92efd4ff67f26 100644
> > --- a/include/linux/blkdev.h
> > +++ b/include/linux/blkdev.h
> > @@ -360,6 +360,9 @@ typedef unsigned int __bitwise blk_features_t;
> >  #define BLK_FEAT_RAID_PARTIAL_STRIPES_EXPENSIVE \
> >  	((__force blk_features_t)(1u << 15))
> >  
> > +/* device writes each atomic write boundary window of a command atomically */
> > +#define BLK_FEAT_ATOMIC_WRITE_MULTI	((__force blk_features_t)(1u << 16))
>
> With this flag set, a request with REQ_ATOMIC may now carry several independent
> atomic writes rather than one. Code that looks at REQ_ATOMIC on a request (e.g.
> blk_insert_cloned_request(), or a future SCSI WRITE ATOMIC user) needs to know
> that. Could the comment here (or Documentation/block/) spell out what REQ_ATOMIC
> means on a merged request, and what a driver must guarantee before setting the
> flag?

Makes sense. I'll update accordingly on both places.

>
> It might also be useful to expose the feature in sysfs next to the other
> atomic_write_* attributes, so users can tell whether merging across boundaries
> is active on a device.

TBH, I was initially hesitant with the idea of adding another attribute.
I'll add it and if we find it not useful we can drop it during review
time.