From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: "NeilBrown" <neilb@suse.de>
Cc: Song Liu <song@kernel.org>,
linux-raid@vger.kernel.org, linux-block@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Lennart Poettering <lennart@poettering.net>
Subject: Re: [PATCH/RFC] md: remove media-change code
Date: Thu, 14 Apr 2022 13:06:36 +0200 [thread overview]
Message-ID: <20220414130636.00002eca@linux.intel.com> (raw)
In-Reply-To: <164991636542.11576.2282590308338864748@noble.neil.brown.name>
On Thu, 14 Apr 2022 16:06:05 +1000
"NeilBrown" <neilb@suse.de> wrote:
> md only ever used the media-change interfaces to trigger a partition
> rescan once the array became active. Normally partition scan only
> happens when the disk is first added, and with md the disk is typically
> inactive when first added.
>
> This rescan can now be achieved by simply setting GD_NEED_PART_SCAN.
> So do that, and remove all the rescan.
>
Hi Neil,
I experimented in this area in the past, mainly on IMSM (external
metadata). My problem is described here:
https://lore.kernel.org/linux-raid/SA0PR11MB4542ECA84F72506B39C3C9F1FFEE0@SA0PR11MB4542.namprd11.prod.outlook.com/
I lost reproduction on newer kernels, probably changes in block layer hide
issue, it seems to be time race. The change you proposed could bring the issue
back.
The current way is working, so I consider your change as potentially dangerous.
Anyway, I will help with testing if Song decides to take it.
For external metadata we should impose partition read after mdmon start (when
md device becomes RW), so it should be synchronized with mdadm.
It could break autostart functionality for native metadata (if it is still
in use).
Eventually, external metadata should be handled separately.
Thanks,
Mariusz
prev parent reply other threads:[~2022-04-14 11:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-14 6:06 [PATCH/RFC] md: remove media-change code NeilBrown
2022-04-14 11:06 ` Mariusz Tkaczyk [this message]
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=20220414130636.00002eca@linux.intel.com \
--to=mariusz.tkaczyk@linux.intel.com \
--cc=lennart@poettering.net \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=song@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).