All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
To: John Garry <john.g.garry@oracle.com>,
	song@kernel.org, yukuai@fygo.io, magiclinan@didiglobal.com,
	xiao@kernel.org, axboe@kernel.dk, martin.petersen@oracle.com,
	linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH v4 3/7] md/raid10: consistently fail atomic writes that require splitting
Date: Wed, 15 Jul 2026 13:16:45 +0200	[thread overview]
Message-ID: <m2o6g8ec4i.fsf@gmail.com> (raw)
In-Reply-To: <f8554f5b-5a3f-4972-8bea-36fe983ded5e@oracle.com>


Hi John,

On Wed, Jul 15, 2026 at 11:49 +0100, John Garry wrote:
> On 15/07/2026 11:05, Abd-Alrhman Masalkhi wrote:
>> On Wed, Jul 15, 2026 at 10:25 +0100, John Garry wrote:
>>> On 10/07/2026 11:15, Abd-Alrhman Masalkhi wrote:
>>>> RAID10 currently handles one badblock path explicitly by failing atomic
>>>> writes with EIO. However, another badblock path can also reduce the
>>>> writable range and force the bio through bio_submit_split_bioset(),
>>>
>>> What is this other badblock path which you are referring to?
>>>
>> The other path is when the requested write overlaps a bad-block region
>> from the beginning, but the intended write extends beyond the bad-block
>> region. In that case, the current code silently reduces max_sectors.
>> As a result, we end up calling bio_submit_split_bioset(), which
>> completes the bio with -EINVAL rather than -EIO. This is the same issue
>> that existed in raid1 and was fixed by patch 2.
>
> OK, it would be nice to add a concise version of that info to the commit 
> log.
>
Thanks. I'll update the commit log accordingly and send v5.

> Reviewed-by: John Garry <john.g.garry@oracle.com>

-- 
Best Regards,
Abd-Alrhman

  reply	other threads:[~2026-07-15 11:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10 10:15 [PATCH v4 0/7] md/raid10: fixes, atomic write handling, and error-path cleanup Abd-Alrhman Masalkhi
2026-07-10 10:15 ` [PATCH v4 1/7] md/raid10: fix r10bio leak in raid10_write_request() error paths Abd-Alrhman Masalkhi
2026-07-10 10:31   ` sashiko-bot
2026-07-15  7:35   ` yu kuai
2026-07-10 10:15 ` [PATCH v4 2/7] md/raid1: restrict atomic write limits and handle runtime constraints Abd-Alrhman Masalkhi
2026-07-15  9:09   ` yu kuai
2026-07-10 10:15 ` [PATCH v4 3/7] md/raid10: consistently fail atomic writes that require splitting Abd-Alrhman Masalkhi
2026-07-10 10:28   ` sashiko-bot
2026-07-15  9:10   ` yu kuai
2026-07-15  9:25   ` John Garry
2026-07-15 10:05     ` Abd-Alrhman Masalkhi
2026-07-15 10:49       ` John Garry
2026-07-15 11:16         ` Abd-Alrhman Masalkhi [this message]
2026-07-10 10:15 ` [PATCH v4 4/7] md/raid10: remove unnecessary barrier around bio_submit_split_bioset() Abd-Alrhman Masalkhi
2026-07-10 10:15 ` [PATCH v4 5/7] md/raid10: replace wait loop with wait_event_idle() Abd-Alrhman Masalkhi
2026-07-10 10:15 ` [PATCH v4 6/7] md/raid10: simplify write request error handling Abd-Alrhman Masalkhi
2026-07-10 10:15 ` [PATCH v4 7/7] md/raid10: simplify read " Abd-Alrhman Masalkhi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2o6g8ec4i.fsf@gmail.com \
    --to=abd.masalkhi@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=john.g.garry@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=magiclinan@didiglobal.com \
    --cc=martin.petersen@oracle.com \
    --cc=song@kernel.org \
    --cc=xiao@kernel.org \
    --cc=yukuai@fygo.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.