From: NeilBrown <neilb@suse.de>
To: "David F." <df7729@gmail.com>
Cc: Martin Wilck <mwilck@arcor.de>, linux-raid@vger.kernel.org
Subject: Re: MDADM 3.3 broken?
Date: Wed, 20 Nov 2013 13:30:16 +1100 [thread overview]
Message-ID: <20131120133016.7de2d400@notabene.brown> (raw)
In-Reply-To: <CAGRSmLvv0-MRyKV89W4zDi57Fhx8dxEUsR+zskOQ0R-H6x4Zbw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3094 bytes --]
On Tue, 19 Nov 2013 17:34:29 -0800 "David F." <df7729@gmail.com> wrote:
> Contents of /proc/partitions:
> major minor #blocks name
>
> 8 32 143638992 sdc
> 8 33 102400 sdc1
> 8 34 143535568 sdc2
> 8 48 143638992 sdd
> 8 64 143638992 sde
> 8 80 143638992 sdf
> 8 81 102400 sdf1
> 8 82 143535568 sdf2
> 8 96 143638992 sdg
> 11 0 48160 sr0
> 8 16 7632892 sdb
This seems to suggest that there are no md devices that are active.
> Contents of /proc/mdstat (Linux software RAID status):
> Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
> [raid4] [multipath]
> md127 : inactive sdg[0](S)
> 1061328 blocks super external:ddf
>
> unused devices: <none>
And this confirms it - just md127 which is inactive and is a ddf 'container'.
> Contents of /etc/mdadm/mdadm.conf (Linux software RAID config file):
> # mdadm.conf
> #
> # Please refer to mdadm.conf(5) for information about this file.
> #
>
> # by default (built-in), scan all partitions (/proc/partitions) and all
> # containers for MD superblocks. alternatively, specify devices to scan, using
> # wildcards if desired.
> DEVICE partitions containers
>
> # automatically tag new arrays as belonging to the local system
> HOMEHOST <system>
>
> ARRAY metadata=ddf UUID=7ab254d0:fae71048:404edde9:750a8a05
> ARRAY container=7ab254d0:fae71048:404edde9:750a8a05 member=0
> UUID=45b3ab73:5c998afc:01bbf815:12660984
This shows that mdadm is expecting a container with
UUID=7ab254d0:fae71048:404edde9:750a8a05
which is presumably found, and a member with
UUID=45b3ab73:5c998afc:01bbf815:12660984
which it presumably has not found.
> >
> >> mdadm --examine --scan
> > ARRAY metadata=ddf UUID=7ab254d0:fae71048:
> > 404edde9:750a8a05
> > ARRAY container=7ab254d0:fae71048:404edde9:750a8a05 member=0
> > UUID=5337ab03:86ca2abc:d42bfbc8:23626c78
This shows that mdadm found a container with the correct UUID, but the member
array inside the container has the wrong uuid.
Martin: I think one of your recent changes would have changed the member UUID
for some specific arrays because the one that was being created before wasn't
reliably stable. Could that apply to David's situation?
David: if you remove the "UUID=" part for the array leaving the
"container=.... member=0" as the identification, does it work?
> >
> >> mdadm --assemble --scan --no-degraded -v
> > mdadm: looking for devices for further assembly
> > mdadm: /dev/md/ddf0 is a container, but we are looking for components
> > mdadm: no RAID superblock on /dev/sdf
> > mdadm: no RAID superblock on /dev/md/MegaSR2
> > mdadm: no RAID superblock on /dev/md/MegaSR1
> > mdadm: no RAID superblock on /dev/md/MegaSR
This seems to suggest that there were 3 md arrays active, where as the
previous data didn't show that. So it seems the two sets of information are
inconsistent and any conclusions I draw are uncertain.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2013-11-20 2:30 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-18 18:26 MDADM 3.3 broken? David F.
2013-11-18 20:22 ` Martin Wilck
2013-11-18 23:13 ` David F.
2013-11-19 0:01 ` NeilBrown
2013-11-19 17:05 ` David F.
2013-11-19 20:38 ` Martin Wilck
2013-11-19 22:34 ` David F.
2013-11-19 22:49 ` David F.
2013-11-19 19:45 ` Martin Wilck
2013-11-19 20:08 ` David F.
2013-11-19 23:51 ` NeilBrown
2013-11-20 0:22 ` David F.
2013-11-20 0:35 ` David F.
2013-11-20 0:48 ` NeilBrown
2013-11-20 1:29 ` David F.
2013-11-20 1:34 ` David F.
2013-11-20 2:30 ` NeilBrown [this message]
2013-11-20 6:41 ` David F.
2013-11-20 23:15 ` David F.
2013-11-21 20:50 ` Martin Wilck
2013-11-21 21:10 ` David F.
2013-11-21 21:30 ` Martin Wilck
2013-11-21 22:39 ` David F.
2013-11-25 21:39 ` Martin Wilck
2013-11-21 20:46 ` Martin Wilck
2013-11-21 21:06 ` David F.
2013-11-21 23:05 ` David F.
2013-11-21 23:09 ` David F.
2013-11-22 3:06 ` David F.
2013-11-22 18:36 ` David F.
2013-11-23 23:36 ` David F.
2013-11-25 21:56 ` Martin Wilck
2013-11-26 0:24 ` David F.
2013-11-26 21:59 ` David F.
2013-11-27 22:40 ` Martin Wilck
2013-12-06 1:53 ` David F.
2013-12-07 2:28 ` David F.
2013-12-07 3:16 ` NeilBrown
2013-12-07 3:46 ` David F.
2013-12-14 21:01 ` David F.
2014-01-20 4:34 ` NeilBrown
2014-01-20 21:52 ` Martin Wilck
2014-01-20 23:54 ` David F.
2014-01-22 22:32 ` David F.
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=20131120133016.7de2d400@notabene.brown \
--to=neilb@suse.de \
--cc=df7729@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=mwilck@arcor.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).