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, vverma@digitalocean.com,
	martin.petersen@oracle.com, abd.masalkhi@gatech.edu,
	linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH v3 2/7] md/raid1: advertise atomic write limits and handle runtime constraints
Date: Fri, 10 Jul 2026 11:42:31 +0200	[thread overview]
Message-ID: <m2bjcfkwoo.fsf@gmail.com> (raw)
In-Reply-To: <350a2662-7de0-45e6-a905-76dbd0a99e98@oracle.com>

On Thu, Jul 09, 2026 at 13:11 +0100, John Garry wrote:
> On 08/07/2026 11:13, Abd-Alrhman Masalkhi wrote:
>> Atomic writes in RAID1 must fit within a single barrier unit. Set
>> chunk_sectors to BARRIER_UNIT_SECTOR_SIZE so that bios which would cross
>> a barrier-unit boundary are rejected by the block layer before reaching
>> MD.
>
> More accurate would be to say that we restrict the atomic write limits 
> so that we never produce a write which straddles BARRIER_UNIT_SECTOR_SIZE.
>
Yes, that is more accurate. I'll update the commit message accordingly.
Thanks for the suggestion.

>> 
>> A bio that passes block-layer validation may still become unserviceable
>> within RAID1 due to bad blocks or write-behind constraints. In the former
>> case, complete the bio with EIO. In the latter case, disable
>> write-behind rather than failing the bio with EIO.
>> 
>> Fixes: f2a38abf5f1c ("md/raid1: Atomic write support")
>> Fixes: a4c55c902670 ("md/raid1: simplify raid1_write_request() error handling")
>> Signed-off-by: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
>
> Reviewed-by: John Garry <john.g.garry@oracle.com>
>
>

-- 
Best Regards,
Abd-Alrhman

  reply	other threads:[~2026-07-10  9:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-08 10:13 [PATCH v3 0/7] md/raid10: fixes, atomic write handling, and error-path cleanup Abd-Alrhman Masalkhi
2026-07-08 10:13 ` [PATCH v3 1/7] md/raid10: fix r10bio leak in raid10_write_request() error paths Abd-Alrhman Masalkhi
2026-07-08 10:33   ` sashiko-bot
2026-07-08 10:13 ` [PATCH v3 2/7] md/raid1: advertise atomic write limits and handle runtime constraints Abd-Alrhman Masalkhi
2026-07-09 12:11   ` John Garry
2026-07-10  9:42     ` Abd-Alrhman Masalkhi [this message]
2026-07-08 10:13 ` [PATCH v3 3/7] md/raid10: consistently fail atomic writes that require splitting Abd-Alrhman Masalkhi
2026-07-08 10:31   ` sashiko-bot
2026-07-08 10:13 ` [PATCH v3 4/7] md/raid10: remove unnecessary barrier around bio_submit_split_bioset() Abd-Alrhman Masalkhi
2026-07-08 10:13 ` [PATCH v3 5/7] md/raid10: replace wait loop with wait_event_idle() Abd-Alrhman Masalkhi
2026-07-08 10:13 ` [PATCH v3 6/7] md/raid10: simplify write request error handling Abd-Alrhman Masalkhi
2026-07-08 10:13 ` [PATCH v3 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=m2bjcfkwoo.fsf@gmail.com \
    --to=abd.masalkhi@gmail.com \
    --cc=abd.masalkhi@gatech.edu \
    --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=vverma@digitalocean.com \
    --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.