From: Sebastian Riemer <sebastian.riemer@profitbricks.com>
To: Hans-Peter Jansen <hpj@urpla.net>
Cc: Linux RAID <linux-raid@vger.kernel.org>, NeilBrown <neilb@suse.de>
Subject: Re: Persistent failures with simple md setup
Date: Wed, 30 Jan 2013 10:07:24 +0100 [thread overview]
Message-ID: <5108E2CC.4010806@profitbricks.com> (raw)
In-Reply-To: <1565063.1kpR7lz4Ph@xrated>
On 29.01.2013 23:14, Hans-Peter Jansen wrote:
[...]
> ~# cat /proc/mdstat
> Personalities : [raid1] [raid0] [raid10] [raid6] [raid5] [raid4]
> md3 : active raid1 sda4[0]
> 869702736 blocks super 1.0 [2/1] [U_]
> bitmap: 57/415 pages [228KB], 1024KB chunk
>
> md0 : active raid1 sda1[0]
> 96376 blocks super 1.0 [2/1] [U_]
> bitmap: 1/6 pages [4KB], 8KB chunk
>
> md1 : active (auto-read-only) raid1 sdb2[1] sda2[0]
> 2096468 blocks super 1.0 [2/2] [UU]
> bitmap: 0/8 pages [0KB], 128KB chunk
>
> md124 : active raid1 sdb3[1] sda3[0]
> 104856180 blocks super 1.0 [2/2] [UU]
> bitmap: 8/200 pages [32KB], 256KB chunk
>
> This looks like some kind of race during device detection.
> The full boot sequence log leading to this mess is attached.
[...]
> Could some kind soul tell me, what's going on here?
Funny, we've observed similar strange behavior when putting MD devices
on iSCSI/SRP exports. We connect to the SCSI target and udev does lots
of crap assembling only 1/2 or even 0/2 devices. This is why we disable
all udev rules related to MD and do it by custom scripts.
In mdadm 3.2.6 a possible fix has been introduced.
Check: git log mdadm-3.2.5..mdadm-3.2.6
commit 090900c3d2eb5b3aef5251a21228483c32246cc7
Author: Harald Hoyer <harald@redhat.com>
Date: Mon Aug 13 08:00:21 2012 +1000
udev-rules: prevent systemd from mount devices before they are ready.
commit b7e05d2373313dd8d0cb687479ad58a88f37d29f
Author: NeilBrown <neilb@suse.de>
Date: Thu May 24 11:49:49 2012 +1000
udev-rules: prevent systemd from mount devices before they are ready.
Does mdadm 3.2.6 solve this?
Cheers,
Sebastian
next prev parent reply other threads:[~2013-01-30 9:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-29 22:14 Persistent failures with simple md setup Hans-Peter Jansen
2013-01-30 9:07 ` Sebastian Riemer [this message]
2013-01-30 17:12 ` Hans-Peter Jansen
2013-02-04 20:43 ` Hans-Peter Jansen
2013-02-05 3:44 ` NeilBrown
2013-02-27 17:01 ` Hans-Peter Jansen
2013-02-28 3:40 ` NeilBrown
2013-02-28 10:49 ` Hans-Peter Jansen
2013-02-28 21:25 ` NeilBrown
2013-02-28 22:16 ` Hans-Peter Jansen
[not found] ` <4291349.FrQcKOnicQ@xrated>
2013-03-03 23:33 ` NeilBrown
2013-03-13 0:52 ` NeilBrown
2013-03-15 22:43 ` Hans-Peter Jansen
2013-03-18 11:20 ` Hans-Peter Jansen
2013-03-21 3:24 ` NeilBrown
2013-04-10 13:28 ` Hans-Peter Jansen
2013-04-10 13:44 ` Hans-Peter Jansen
2013-04-11 7:33 ` NeilBrown
2013-01-30 9:20 ` Roy Sigurd Karlsbakk
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=5108E2CC.4010806@profitbricks.com \
--to=sebastian.riemer@profitbricks.com \
--cc=hpj@urpla.net \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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).