From: NeilBrown <neilb@suse.de>
To: Mark Munoz <mark.munoz@rightthisminute.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: MD RAID Bug 7/15/12
Date: Tue, 2 Oct 2012 12:25:52 +1000 [thread overview]
Message-ID: <20121002122552.7ba6fbb6@notabene.brown> (raw)
In-Reply-To: <FB3CC1EE-F6BD-4446-ADBA-0DC792AAA3DC@rightthisminute.com>
[-- Attachment #1: Type: text/plain, Size: 4847 bytes --]
On Mon, 1 Oct 2012 18:51:09 -0700 Mark Munoz <mark.munoz@rightthisminute.com>
wrote:
> Neil,
>
> Thank you again so much for taking time out of your day to personally help me it really means a lot. I have ran the command and have successfully recreated my md1 Now however md2 will not assemble. I get this error.
>
> sudo mdadm --assemble --force /dev/md2 /dev/md0 /dev/md1
> mdadm: superblock on /dev/md1 doesn't match others - assembly aborted
>
> Would I be correct in thinking that I just need to recreate md2 now as well?
Maybe, but probably not.
I would think it more likely that md1 wasn't created quite right - otherwise
it should have the right metadata.
What does:
mdadm -E /dev/md1
display now? How does that compare with "mdadm -E /dev/md0" ?
What about
mdadm -E /dev/sdaf
(or any other device in md1)? How does that compare to what was displayed
previously?
NeilBrown
>
> I assume with this command?
>
> sudo mdadm --create --assume-clean /dev/md2 --level=0 --chunk=64 --metadata=1.2 --raid-devices=2 /dev/md0 /dev/md1
>
> Mark Munoz
>
> On Oct 1, 2012, at 2:00 PM, Mark Munoz <mark.munoz@rightthisminute.com> wrote:
> >
> >> On Sat, 29 Sep 2012 17:12:40 -0700 Mark Munoz
> >> <mark.munoz@rightthisminute.com> wrote:
> >>
> >>> Hi I appear to have been affected by the bug you found on 7/15/12. The data I have on this array is really important and I want to make sure I get this correct before I actually make changes.
> >>>
> >>> Configuration:
> >>> md0 is a RAID 6 volume with 24 devices and 1 spare. It is working fine and was unaffected.
> >>> md1 is a RAID 6 volume with 19 devices and 1 spare. It was affected. All the drives show as unknown raid level and 0 devices. With the exception of device 5. It has all the information.
> >>>
> >>> Here is the output from that drive:
> >>>
> >>> serveradmin@hulk:/etc/mdadm$ sudo mdadm --examine /dev/sdaf
> >>> /dev/sdaf:
> >>> Magic : a92b4efc
> >>> Version : 1.2
> >>> Feature Map : 0x0
> >>> Array UUID : 6afb3306:144cec30:1b2d1a19:3a56f0d3
> >>> Name : hulk:1 (local to host hulk)
> >>> Creation Time : Wed Aug 15 16:25:30 2012
> >>> Raid Level : raid6
> >>> Raid Devices : 19
> >>>
> >>> Avail Dev Size : 5860531120 (2794.52 GiB 3000.59 GB)
> >>> Array Size : 99629024416 (47506.82 GiB 51010.06 GB)
> >>> Used Dev Size : 5860530848 (2794.52 GiB 3000.59 GB)
> >>> Data Offset : 2048 sectors
> >>> Super Offset : 8 sectors
> >>> State : clean
> >>> Device UUID : 205dfd9f:9be2b9ca:1f775974:fb1b742c
> >>>
> >>> Update Time : Sat Sep 29 12:22:51 2012
> >>> Checksum : 9f164d8e - correct
> >>> Events : 38
> >>>
> >>> Layout : left-symmetric
> >>> Chunk Size : 4K
> >>>
> >>> Device Role : Active device 5
> >>> Array State : AAAAAAAAAAAAAAAAAAA ('A' == active, '.' == missing)
> >>>
> >>> Now I also have md2 which is a striped RAID of both md0 and md1.
> >>>
> >>> When I type:
> >>>
> >>> sudo mdadm --create --assume-clean /dev/md1 --level=6 --chunk=4 --metadata=1.2 --raid-devices=19 /dev/sdaa /dev/sdab /dev/sdac /dev/sdad /dev/sdae /dev/sdaf /dev/sdag /dev/sdah /dev/sdai /dev/sdaj /dev/sdak /dev/sdal /dev/sdam /dev/sdan /dev/sdao /dev/sdap /dev/sdaq /dev/sdar /dev/sdas
> >>>
> >>> the following error for each device.
> >>>
> >>> mdadm: /dev/sdaa appears to be part of a raid array:
> >>> level=-unknown- devices=0 ctime=Wed Aug 15 16:25:30 2012
> >>> mdadm: partition table exists on /dev/sdaa but will be lost or
> >>> meaningless after creating array
> >>>
> >>> I want to make sure by running this above command that I won't affect any of the data of md2 when I assemble that array after creating md1. Any help on this issue would be greatly appreciated. I would normally just DD copies but as you can see I would have to buy 19 more 3TB hard drives as well as the time to DD each drive. It is a production server and that kind of down time would really rather be avoided.
> >>
> >> Running this command will only overwrite the 4K of metadata, 4K from the
> >> start of the devices. It will not write anything else to any device.
> >>
> >> so yes, it is safe.
> >>
> >> NeilBrown
> >>
> >>
> >>
> >>>
> >>> Thank you so much for your time.
> >>>
> >>> Mark Munoz
> >>> 623.523.3201--
> >>> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-10-02 2:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-30 0:12 MD RAID Bug 7/15/12 Mark Munoz
2012-09-30 2:47 ` Chris Murphy
2012-09-30 21:08 ` Stefan /*St0fF*/ Hübner
2012-09-30 22:16 ` Chris Murphy
2012-10-01 22:27 ` Stefan /*St0fF*/ Hübner
2012-10-01 3:02 ` NeilBrown
[not found] ` <42BA87F6-C5A3-4321-A4C7-0DCF0A9DF79D@rightthisminute.com>
2012-10-02 1:51 ` Mark Munoz
2012-10-02 2:25 ` NeilBrown [this message]
[not found] ` <20121002114920.1029bed7@notabene.brown>
2012-10-02 2:33 ` Mark Munoz
2012-10-02 5:07 ` NeilBrown
2012-10-02 22:53 ` Mark Munoz
2012-10-03 1:54 ` 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=20121002122552.7ba6fbb6@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=mark.munoz@rightthisminute.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).