Re: [PATCH v2 2/7] md/raid1: advertise atomic write limits and handle runtime constraints
From: John Garry
Date: Tue Jul 07 2026 - 12:21:28 EST
On 06/07/2026 12:35, Abd-Alrhman Masalkhi wrote:
well it seems to be that everything in the driver is split overI checked blk_stack_atomic_writes_limits(), and you are right: setting
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()
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