Re: [PATCH 2/7] md/raid1: handle atomic writes that require splitting
From: John Garry
Date: Tue Jun 23 2026 - 07:39:12 EST
On 23/06/2026 11:06, Abd-Alrhman Masalkhi wrote:
On Tue, Jun 23, 2026 at 10:20 +0100, John Garry wrote:
On 23/06/2026 09:58, Abd-Alrhman Masalkhi wrote:
On Tue, Jun 23, 2026 at 09:11 +0100, John Garry wrote:
On 23/06/2026 08:24, Abd-Alrhman Masalkhi wrote:The request size itself satisfies the currently advertised atomic write
If a request already requires splitting when entering
raid1_write_request(), the current code allows it to proceed until it
eventually reaches the split path.
The block layer should catch invalid atomic writes in
submit_bio_noacct() -> blk_validate_atomic_write_op_size() before we
even get as far as the md atomic write handling. Having the check in
bio_submit_split_bioset() is really just a fail-safe for the block layer
not catching invalid atomic writes or the atomic writes queue limits not
being properly calculated.
limits, so blk_validate_atomic_write_op_size() allows it. The problem
is that RAID1 may further restrict atomic writes to a single barrier
unit via align_to_barrier_unit_end(). Therefore a request that crosses
a barrier-unit boundary can still reach raid1_write_request() with
max_sectors < bio_sectors(bio).
If the barrier-unit restriction should instead be advertised through the
atomic write queue limits,
It should. Any restrictions should be advertised up front. For the user
to issue an atomic write which is valid according to limits, then it
should succeed.
I'll take a look at how best to expose that through the queue limits and
rework this part accordingly. If there is already an existing mechanism
you had in mind, I'd appreciate any pointers.
Any write must fit within BARRIER_UNIT_SECTOR_SIZE, right?
Since an atomic write must be naturally aligned, then I would expect that the atomic write max unit is limited by BARRIER_UNIT_SECTOR_SIZE.
then I agree the block layer could reject
such requests earlier and the RAID1 entry check would become
unnecessary.
However, there are also cases where max_sectors is reduced later within
raid1_write_request(), for example when bad blocks are present on some
mirrors (or due to other RAID1-specific constraints such as write-behind
limits). Those reductions depend on RAID1 runtime state and mirror
health, so they are not readily visible to the block layer during atomic
write validation. In those cases RAID1 still needs to detect that the
atomic write can no longer be serviced as requested and fail it
appropriately.
Sure, and we do this. As I remember, we should return -EIO in this case.
Right, and that's the main motivation for this patch. The original
atomic write support already returned -EIO for one bad-block path, but
there are other cases where max_sectors can be reduced (e.g. the
first_bad <= sector path and write-behind limits)
After a4c55c902670, those cases can end up completing with EINVAL or
NOTSUPP instead. This patch is intended to restore consistent -EIO.
ok, but I could not check this as I did not recognize the baseline code.
Along the way, the bio may instead
fail due to other conditions and return a different status, even though
the request was invalid as an atomic write from the beginning.