From: Xiao Ni <xni@redhat.com>
To: Zhilong Liu <zlliu@suse.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: The dev node can't be released at once after stopping raid
Date: Thu, 1 Jun 2017 01:50:38 -0400 (EDT) [thread overview]
Message-ID: <1471667815.16472496.1496296238179.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <43bca632-9d77-2063-603c-6dcf47f3d250@suse.com>
----- Original Message -----
> From: "Zhilong Liu" <zlliu@suse.com>
> To: "Xiao Ni" <xni@redhat.com>, linux-raid@vger.kernel.org
> Sent: Thursday, June 1, 2017 12:43:49 PM
> Subject: Re: The dev node can't be released at once after stopping raid
>
>
>
> On 06/01/2017 11:47 AM, Xiao Ni wrote:
> > Hi all
> >
> > I tried with the latest linux stable kernel and latest mdadm.
> >
> > After stopping a raid device, the dev node directory can't be released
> > at once. I did a simple test, the script is:
> >
> > #!/bin/sh
> >
> > while [ 1 ]; do
> > mdadm -CR /dev/md0 -l1 -n2 /dev/loop0 /dev/loop1
> > sleep 5
> > mdadm -S /dev/md0
> > ls /dev/md0
> > sleep 1
> > ls /dev/md0
> > done
> >
> > mdadm: stopped /dev/md0
> > /dev/md0
> > ls: cannot access /dev/md0: No such file or directory
> >
> > It usually detects dev node /dev/md0 isn't released after stopping raid.
> > I'm not sure whether it's a bug or not. Do we need to do some job to
> > make sure that the node should be released before command mdadm -S return?
>
> it's waiting for processing the udev events. we can monitor it via to "#
> udevadm monitor".
>
> For mdadm -S /dev/md0, Manage_stop() has already did the errno checking,
>
> cut piece of code from Manage.c
> .. .. .. ..
> done:
>
> /* As we have an O_EXCL open, any use of the device
> * which blocks STOP_ARRAY is probably a transient use,
> * so it is reasonable to retry for a while - 5 seconds.
> */
> count = 25; err = 0;
> while (count && fd >= 0 &&
> (err = ioctl(fd, STOP_ARRAY, NULL)) < 0 && errno == EBUSY) {
> usleep(200000);
> count --;
> }
Hi Zhilong
Good suggestions. I tried it and it can add some codes in the script to wait.
Is it better to check the udev events in mdadm? Let's check it after closing
mdfd when Manage_stop returns. Because it's mdadm's job, right?
Regards
Xiao
>
> Best regards,
> -Zhilong
>
> > Best Regards
> > Xiao
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2017-06-01 5:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <51439640.15505639.1496113073965.JavaMail.zimbra@redhat.com>
2017-06-01 3:47 ` The dev node can't be released at once after stopping raid Xiao Ni
2017-06-01 4:43 ` Zhilong Liu
2017-06-01 5:50 ` Xiao Ni [this message]
2017-08-31 3:55 ` Xiao Ni
2017-08-31 4:36 ` NeilBrown
2017-08-31 6:17 ` Xiao Ni
2017-08-31 6:48 ` NeilBrown
2017-08-31 7:16 ` Xiao Ni
2017-08-31 23:39 ` NeilBrown
2017-09-01 0:30 ` Xiao Ni
2017-09-01 4:34 ` NeilBrown
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=1471667815.16472496.1496296238179.JavaMail.zimbra@redhat.com \
--to=xni@redhat.com \
--cc=linux-raid@vger.kernel.org \
--cc=zlliu@suse.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;
as well as URLs for NNTP newsgroup(s).