From: NeilBrown <neilb@suse.com>
To: Marc Smith <marc.smith@mcc.edu>, linux-raid@vger.kernel.org
Subject: Re: MD Remnants After --stop
Date: Mon, 07 Nov 2016 16:44:18 +1100 [thread overview]
Message-ID: <87fun3ond9.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <CAHkw+Lf1SErbGro4bq5MM5LyB-Zqyqi4E90R7c+uAZHv1WgSrA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]
On Sat, Nov 05 2016, Marc Smith wrote:
> Hi,
>
> It may be that I've never noticed this before, so maybe its not a
> problem... after using '--stop' to deactivate/stop an MD array, there
> are remnants of it lingering, namely an entry in /sys/block (eg,
> /sys/block/md127) and the device node in /dev remains (eg,
> /dev/md127).
>
> Is this normal? Like I said, it probably is, and I've just never
> noticed it before. I assume its not going to hurt anything, but is
> there a way to clean it up, without rebooting? Obviously I could
> remove the /dev entry, but what about /sys/block?
>
You can remove them both by running
mdadm -S /dev/md127
but they'll probably just reappear again.
This seems to be an on-going battle between md and udev. I've "fixed"
it at least once, but it keeps coming back.
When md removes the md127 device, a message is sent to udev.
As part of its response to this message, udev tries to open /dev/md127.
Because of the rather unusual way that md devices are created (it made
sense nearly 20 years ago when it was designed), opening /dev/md127
causes md to create device md127 again.
You could
mv /dev/md127 /dev/md127X
mdadm -S /dev/md127X
rm /dev/md127X
that stop udev from opening /dev/md127. It seems to work reliably.
md used to generate a CHANGE event before the REMOVE event, and only the
CHANGE event caused udev to open the device file. I removed that and
the problem went away. Apparently some change has happened to udev and
now it opens the file in response to REMOVE as well.
So to "fix" it again, you need to figure out what udev is doing and fix
that.
Alternately... place "create names=yes" in your mdadm.conf
and always use names, not numbers, to work with md arrays.
e.g. /dev/md/home /dev/md/root /dev/md/scratch etc.
When will trigger the use of an alternate scheme for creating md devices
(using minor numbers >= 512) which udev cannot break so easily. When it
tries to open /dev/md_home, that will fail.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
next prev parent reply other threads:[~2016-11-07 5:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 15:35 MD Remnants After --stop Marc Smith
2016-11-07 5:44 ` NeilBrown [this message]
2016-11-18 19:31 ` Marc Smith
2016-11-21 3:42 ` NeilBrown
2016-11-21 14:08 ` Marc Smith
2016-11-22 15:12 ` Marc Smith
2016-11-22 23:51 ` NeilBrown
2016-11-23 15:21 ` Marc Smith
2016-11-23 23:38 ` NeilBrown
2016-11-26 16:41 ` Marc Smith
2016-11-27 22:20 ` NeilBrown
2016-11-28 2:25 ` Marc Smith
2016-12-01 2:52 ` NeilBrown
2016-12-01 19:40 ` Marc Smith
2016-12-01 22:35 ` NeilBrown
2016-12-02 18:18 ` Stephane Thiell
2016-12-02 19:12 ` Marc Smith
2016-12-02 20:22 ` Marc Smith
2016-12-05 0:41 ` NeilBrown
2016-12-05 21:37 ` Marc Smith
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=87fun3ond9.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=linux-raid@vger.kernel.org \
--cc=marc.smith@mcc.edu \
/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).