Linux RAID subsystem development
 help / color / mirror / Atom feed
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

  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