Re: [PATCH v2 2/7] md/raid1: advertise atomic write limits and handle runtime constraints

On 06/07/2026 12:35, Abd-Alrhman Masalkhi wrote:
>> well it seems to be that everything in the driver is split over
>> BARRIER_UNIT_SECTOR_SIZE, so is in effect a chunk size.
>>
>> Note that atomic_write_hw_unit_max is going to be small always compared
>> to BARRIER_UNIT_SECTOR_SIZE.
>>
>> However, can you check the blk stacking code to make sure that this does
>> as you want? As I remember, for stacking we take the atomic write limits
>> of the first bottom device and then stack the other bottom devices and I
>> don't think that setting atomic_write_hw_unit_max in this way has an
>> impact - see blk_stack_atomic_writes_limits()
>>
> I checked blk_stack_atomic_writes_limits(), and you are right: setting
> atomic_write_hw_unit_max here alone does not have the intended effect on
> the final stacked device.
> 
> Also, since atomic_write_hw_unit_max is expected to always be smaller
> than BARRIER_UNIT_SECTOR_SIZE, 

Yes, always expected to be much smaller.

> it seems that there is no need to set an
> additional atomic write limit in raid1, or even to set
> atomic_write_hw_unit_max at all. Is that what you mean?

Even though we expect it to be much smaller, it's good practice to 
ensure this.

One method to do so - which I already mentioned - was to set the chunk 
size to BARRIER_UNIT_SECTOR_SIZE. You were not keen on that.

Another method is to set max hw sectors for the RAID1 device to 
BARRIER_UNIT_SECTOR_SIZE.

Thanks,
John