From: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
To: Sebastian Parschauer <sebastian.riemer@profitbricks.com>,
NeilBrown <neilb@suse.de>,
Francis Moreau <francis.moro@gmail.com>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: /sys/block/md126 still exists even after stopping the array
Date: Thu, 24 Jul 2014 15:51:22 +0200 [thread overview]
Message-ID: <53D10F5A.8030107@intel.com> (raw)
In-Reply-To: <53D10CC6.4070009@profitbricks.com>
On 07/24/2014 03:40 PM, Sebastian Parschauer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 25.06.2014 03:03, NeilBrown wrote:
>> On Tue, 24 Jun 2014 17:38:30 +0200 Francis Moreau
>> <francis.moro@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I'm having the folloing behaviour with kernel 3.14.5 and mdadm
>>> v3.3.1.
>>>
>>> After stopping all arrays, I still can see one of them in
>>> /sys/block/:
>>>
>>> # cat /proc/mdstat Personalities : [raid1] md125 : active raid1
>>> sdb3[1] sda3[0] 483688448 blocks super 1.2 [2/2] [UU]
>>> [======>..............] resync = 34.9% (169161280/483688448)
>>> finish=44.0min speed=118852K/sec bitmap: 3/4 pages [12KB],
>>> 65536KB chunk
>>>
>>> md126 : active raid1 sdb2[1] sda2[0] 4038656 blocks super 1.2
>>> [2/2] [UU]
>>>
>>> md127 : active raid1 sdb1[1] sda1[0] 524224 blocks super 1.0
>>> [2/2] [UU]
>>>
>>> unused devices: <none>
>>>
>>> # mdadm --stop /dev/md12[567] mdadm: stopped /dev/md125 mdadm:
>>> stopped /dev/md126 mdadm: stopped /dev/md127
>>>
>>> # cat /proc/mdstat Personalities : [raid1] unused devices:
>>> <none>
>>>
>>> # ls /sys/block/ md126 sda sdb sdc sr0
>>>
>>> # ls /sys/block/md126/md/ array_size array_state bitmap
>>> chunk_size component_size layout level max_read_errors
>>> metadata_version new_dev raid_disks reshape_direction
>>> reshape_position resync_start safe_mode_delay
>>>
>>> # dmesg .... [ 1573.715476] md125: detected capacity change from
>>> 495296970752 to 0 [ 1573.715626] md: md125 stopped. [
>>> 1573.715633] md: unbind<sdb3> [ 1573.740681] md:
>>> export_rdev(sdb3) [ 1573.740694] md: unbind<sda3> [ 1573.754008]
>>> md: export_rdev(sda3) [ 1573.773398] md126: detected capacity
>>> change from 4135583744 to 0 [ 1573.773403] md: md126 stopped. [
>>> 1573.773410] md: unbind<sdb2> [ 1573.820652] md:
>>> export_rdev(sdb2) [ 1573.820664] md: unbind<sda2> [ 1573.873974]
>>> md: export_rdev(sda2) [ 1573.889904] md127: detected capacity
>>> change from 536805376 to 0 [ 1573.889910] md: md127 stopped. [
>>> 1573.889917] md: unbind<sdb1> [ 1573.913978] md:
>>> export_rdev(sdb1) [ 1573.914033] md: unbind<sda1> [ 1573.940627]
>>> md: export_rdev(sda1)
>>>
>>> After waiting a couple of min, stopping again md126 worked:
>>>
>>> [ 1835.755661] md: md126 stopped.
>>>
>>> Is this expected ?
>>
>> No overly surprising.
>>
>> This is probably caused by udev, or something udev runs, opening
>> /dev/md126 after it has been stopped. This has the effect of
>> creating an empty inactive array. e.g.
>>
>> mknod /dev/test b 9 57 < /dev/test
>>
>> will make /sys/block/md57 appear.
>>
>> It is a bit untidy, but shouldn't cause problems.
>>
>> NeilBrown
>>
>
>
> Hi Neil,
>
> we are also noticing this issue with udev-215 on Gentoo. They've
> switched over to systemd. Deactivating all udev rules doesn't help. So
> it must be an issue in the code. udev-204 works fine.
> When stopping udev, then it is possible to stop the MD array and it
> remains stopped (/sys/block/mdX disappears). Looks like they do
> something really strange there.
>
> Do you have any advice how to fix this in another way but to change
> the kernel or to downgrade udev?
>
> File a systemd bug?
Hi,
I have also noticed this issue. It is caused by this change in udev:
commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
Author: Kay Sievers <kay at vrfy.org>
Date: Sun Apr 13 19:54:27 2014 -0700
udev: serialize/synchronize block device event handling with file locks
http://cgit.freedesktop.org/systemd/systemd/commit/?id=3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
It seems that they have already disabled this for dm for some reason,
but not for md:
commit e918a1b5a94f270186dca59156354acd2a596494
Author: Kay Sievers <kay@vrfy.org>
Date: Tue Jun 3 16:49:38 2014 +0200
udev: exclude device-mapper from block device ownership event locking
http://cgit.freedesktop.org/systemd/systemd/commit/?id=e918a1b5a94f270186dca59156354acd2a596494
Artur
next prev parent reply other threads:[~2014-07-24 13:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-24 15:38 /sys/block/md126 still exists even after stopping the array Francis Moreau
2014-06-25 1:03 ` NeilBrown
2014-06-25 6:59 ` Francis Moreau
2014-07-24 13:40 ` Sebastian Parschauer
2014-07-24 13:51 ` Artur Paszkiewicz [this message]
2014-09-25 16:12 ` Francis Moreau
2014-09-26 0:33 ` NeilBrown
2014-09-26 10:23 ` Francis Moreau
2014-09-26 10:44 ` NeilBrown
2014-09-26 11:23 ` Artur Paszkiewicz
2014-09-29 4:19 ` NeilBrown
2014-09-26 12:21 ` Francis Moreau
2014-09-26 12:50 ` Francis Moreau
2014-09-29 4:47 ` NeilBrown
2014-09-29 4:37 ` NeilBrown
2014-09-29 8:45 ` Francis Moreau
2014-09-29 21:56 ` NeilBrown
2014-09-30 7:43 ` Francis Moreau
2014-10-07 7:05 ` Francis Moreau
2014-10-07 23:54 ` NeilBrown
2014-10-09 9:40 ` Francis Moreau
2014-10-09 9:55 ` NeilBrown
2014-10-10 19:34 ` Francis Moreau
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=53D10F5A.8030107@intel.com \
--to=artur.paszkiewicz@intel.com \
--cc=francis.moro@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=sebastian.riemer@profitbricks.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).