From: Yunye Zhao <yunye.zhao@linux.alibaba.com>
To: Mykola Marzhan <mykola@meshstor.io>
Cc: Song Liu <song@kernel.org>, Yu Kuai <yukuai@fygo.io>,
Li Nan <magiclinan@didiglobal.com>, Xiao Ni <xiao@kernel.org>,
Joseph Qi <joseph.qi@linux.alibaba.com>,
Paul Menzel <pmenzel@molgen.mpg.de>,
linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] md/raid10: fix still_degraded being inverted in raid10_sync_request()
Date: Mon, 27 Jul 2026 10:43:47 +0800 [thread overview]
Message-ID: <20260727024347.90544-1-yunye.zhao@linux.alibaba.com> (raw)
In-Reply-To: <20260726122512.2176105-1-mykola@meshstor.io>
Hi,
> I posted the same one-liner on 19 July -- flagging it only so it is not
> applied twice:
>
> https://lore.kernel.org/linux-raid/20260719144227.940444-2-mykola@meshstor.io/
>
> No objection to yours going in, and I will drop mine if it does:
>
> Reviewed-by: Mykola Marzhan <mykola@meshstor.io>
>
> Identical hunk and the same Fixes: tag. Mine picked up Reviewed-by from
> Yu Kuai and Paul Menzel on that posting.
> Your changelog is the better of the two: it carries a measured
> reproducer where mine only reasons through the failure.
Thanks, and apologies for the duplication -- I missed your earlier
posting. Yours was first on the list and already carries tags from
Kuai and Paul, so I am equally happy if the maintainers take your
copy instead. If mine is picked up, I will carry your Reviewed-by
and a Link: to your posting should a v3 be needed.
> Your patch 3 and patch 2 of my 19 July series hit the same unit mismatch
> -- raid10's recovery cursor is in per-device space while its bitmap is
> indexed by array sectors -- but at different sites, and they do not
> overlap:
>
> https://lore.kernel.org/linux-raid/20260719144227.940444-3-mykola@meshstor.io/
>
> Yours converts the bitmap-reported span into per-device sectors inside
> raid10_sync_request(); mine stops md_do_sync() handing
> bitmap_ops->skip_sync_blocks() an offset raid10 cannot interpret. Both
> are still needed. Yu Kuai has asked me to re-check mine against his
> llbitmap reshape series, so mine is still under discussion.
Agreed.
Your fix addresses the llbitmap mis-skip: md_do_sync() feeds the
per-device recovery cursor to skip_sync_blocks(), which llbitmap
indexes by array sectors, and once it answers for the wrong chunk
md_do_sync() takes "goto update" without ever entering
raid10_sync_request() -- so this has to be fixed at the caller, as
your patch does.
My patch 3 addresses the recovery crawl on a mostly-clean bitmap:
the classic bitmap does not implement skip_sync_blocks() at all, and
with your gate in place raid10 recovery no longer consults the
bitmap from md_do_sync() either way -- the layout-aware bulk skip
inside raid10_sync_request() then serves as raid10's fast path for
both bitmap flavours (it sits on start_sync(), which llbitmap also
implements).
The hunks are disjoint as well -- your series touches the
skip_sync_blocks() gate in md_do_sync() plus md.h/raid1/raid5, mine
touches raid10.c and a cond_resched() ~30 lines below your md.c hunk
-- so they apply cleanly in either order.
So both are needed, whichever order they land in. I will follow
your discussion with Kuai on the llbitmap reshape series.
Thanks,
Yunye
next prev parent reply other threads:[~2026-07-27 2:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 6:27 [PATCH] md: fix soft lockup during resync when sync is repeatedly skipped Yunye Zhao
2026-07-17 6:51 ` sashiko-bot
2026-07-19 10:45 ` yu kuai
2026-07-20 6:20 ` Yunye Zhao
2026-07-22 4:00 ` yu kuai
2026-07-23 13:55 ` [PATCH v2 0/3] md/raid10: fix recovery corruption and soft lockup on large arrays Yunye Zhao
2026-07-23 13:55 ` [PATCH v2 1/3] md/raid10: fix still_degraded being inverted in raid10_sync_request() Yunye Zhao
2026-07-26 12:25 ` Mykola Marzhan
2026-07-27 2:43 ` Yunye Zhao [this message]
2026-07-23 13:55 ` [PATCH v2 2/3] md: add cond_resched() to md_do_sync()'s skip path Yunye Zhao
2026-07-23 14:05 ` sashiko-bot
2026-07-23 13:55 ` [PATCH v2 3/3] md/raid10: skip clean regions in bulk during recovery Yunye Zhao
2026-07-23 14:16 ` sashiko-bot
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=20260727024347.90544-1-yunye.zhao@linux.alibaba.com \
--to=yunye.zhao@linux.alibaba.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=magiclinan@didiglobal.com \
--cc=mykola@meshstor.io \
--cc=pmenzel@molgen.mpg.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox