From: Guoqing Jiang <guoqing.jiang@linux.dev>
To: Logan Gunthorpe <logang@deltatee.com>,
linux-raid@vger.kernel.org, Jes Sorensen <jsorensen@fb.com>
Cc: Song Liu <song@kernel.org>, Christoph Hellwig <hch@infradead.org>,
Donald Buczek <buczek@molgen.mpg.de>, Xiao Ni <xni@redhat.com>,
Himanshu Madhani <himanshu.madhani@oracle.com>,
Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>,
Coly Li <colyli@suse.de>, Bruce Dubbs <bruce.dubbs@gmail.com>,
Stephen Bates <sbates@raithlin.com>,
Martin Oliveira <Martin.Oliveira@eideticom.com>,
David Sloan <David.Sloan@eideticom.com>
Subject: Re: [PATCH mdadm] mdadm: Don't open md device for CREATE and ASSEMBLE
Date: Fri, 15 Jul 2022 10:20:26 +0800 [thread overview]
Message-ID: <150ffbb2-9881-9c1f-cc5e-331926b8e423@linux.dev> (raw)
In-Reply-To: <20220714223749.17250-1-logang@deltatee.com>
On 7/15/22 6:37 AM, Logan Gunthorpe wrote:
> The mdadm command tries to open the md device for most modes, first
> thing, no matter what. When running to create or assemble an array,
> in most cases, the md device will not exist, the open call will fail
> and everything will proceed correctly.
I guess the BUILD mode doesn't need to create md as well since commit
7f91af49ad09 ("Delay creation of array devices for assemble/build/create").
> However, when running tests, a create or assembly command may be run
> shortly after stopping an array and the old md device file may still
> be around. Then, if create_on_open is set in the kernel, a new md
> device will be created when mdadm does its initial open.
>
> When mdadm gets around to creating the new device with the new_array
> parameter it issues this error:
>
> mdadm: Fail to create md0 when using
> /sys/module/md_mod/parameters/new_array, fallback to creation via node
>
> This is because an mddev was already created by the kernel with the
> earlier open() call and thus the new one being created will fail with
> EEXIST. The mdadm command will still successfully be created due to
> falling back to the node creation method. However, the error message
> itself will fail any test that's running it.
>
> This issue is a race condition that is very rare, but a recent change
> in the kernel caused this to happen more frequently: about 1 in 50
> times.
>
> To fix this, don't bother trying to open the md device for CREATE and
> ASSEMBLE commands, as the file descriptor will never be used anyway
> even if it is successfully openned.
>
> Side note: it would be nice to disable create_on_open as well to help
> solve this, but it seems the work for this was never finished. By default,
> mdadm will create using the old node interface when a name is specified
> unless the user specifically puts names=yes in a config file, which
> doesn't seem to be vcreate_on_openery common yet.
Hmm, 'create_on_open' is default to true, not sure if there is any side
effect
after change to false.
> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
> ---
> mdadm.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/mdadm.c b/mdadm.c
> index 56722ed997a2..3b886b5c0639 100644
> --- a/mdadm.c
> +++ b/mdadm.c
> @@ -1347,8 +1347,7 @@ int main(int argc, char *argv[])
> * an md device. We check that here and open it.
> */
>
> - if (mode == MANAGE || mode == BUILD || mode == CREATE ||
> - mode == GROW || (mode == ASSEMBLE && ! c.scan)) {
> + if (mode == MANAGE || mode == BUILD || mode == GROW) {
> if (devs_found < 1) {
> pr_err("an md device must be given in this mode\n");
> exit(2);
I think it is a reasonable change.
Thanks,
Guoqing
next prev parent reply other threads:[~2022-07-15 2:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-14 22:37 [PATCH mdadm] mdadm: Don't open md device for CREATE and ASSEMBLE Logan Gunthorpe
2022-07-15 2:20 ` Guoqing Jiang [this message]
2022-07-19 11:27 ` Mariusz Tkaczyk
2022-07-19 16:43 ` Logan Gunthorpe
2022-07-20 8:20 ` Mariusz Tkaczyk
2022-08-23 13:49 ` Jes Sorensen
2022-08-23 14:07 ` Mariusz Tkaczyk
2022-08-23 14:10 ` Jes Sorensen
2022-07-20 18:59 ` Wols Lists
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=150ffbb2-9881-9c1f-cc5e-331926b8e423@linux.dev \
--to=guoqing.jiang@linux.dev \
--cc=David.Sloan@eideticom.com \
--cc=Martin.Oliveira@eideticom.com \
--cc=bruce.dubbs@gmail.com \
--cc=buczek@molgen.mpg.de \
--cc=colyli@suse.de \
--cc=hch@infradead.org \
--cc=himanshu.madhani@oracle.com \
--cc=jsorensen@fb.com \
--cc=linux-raid@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=mariusz.tkaczyk@linux.intel.com \
--cc=sbates@raithlin.com \
--cc=song@kernel.org \
--cc=xni@redhat.com \
/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