From: Phil Turmel <philip@turmel.org>
To: Johannes Truschnigg <johannes@truschnigg.info>
Cc: linux-raid@vger.kernel.org
Subject: Re: What just happened to my disks/RAID5 array?
Date: Fri, 06 Jan 2012 08:16:00 -0500 [thread overview]
Message-ID: <4F06F410.4070807@turmel.org> (raw)
In-Reply-To: <20120106105143.GA2932@vault.local>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Good Morning, Johannes,
On 01/06/2012 05:51 AM, Johannes Truschnigg wrote:
> Hello again Phil and everyone else who's having a peek,
>
> you see, I finally had the chance to migrate all the disks to a new machine,
> and figured I'd try my luck at getting back the data on my precious array.
> It's been a while since I had access to it, but having that data available all
> the time is not as important as having it at all, as I use the box mostly to
> store old(er) backups. I definitely would like to have them back at some point
> in time, however ;)
>
> So yesterday, I upgraded all the software on the boot drive (running Gentoo),
> and now I have Kernel 3.2.0 and mdadm 3.1.5, and all the drives attached to an
> AMD SB850 in AHCI mode. Drive-wise, everything looks as expected - all device
> nodes are there, fdisk reports the correct size, and SMART data can be read
> w/o problems. Assemling the array, however, fails, and I promised in a
> previous mail in this thread that I were to come back to the list and post the
> info I got before venturing forth. Well, here I am now:
Warning! I saw bug report on LKML yesterday involving LVM and the brand new
kernel v3.2, so you might want to pull back. v3.1.5 was known good in that
report.
> I have the array in stopped state, so /proc/mdstat contains no arrays at this
> time. Now I run the following command which yields this output:
>
> --- snip ---
> # mdadm -v --assemble -u "19e260e6:db3cad86:0541487d:a1bae605" /dev/md0
> mdadm: looking for devices for /dev/md0
> mdadm: cannot open device /dev/sda1: Device or resource busy
> mdadm: /dev/sda1 has wrong uuid.
> mdadm: cannot open device /dev/sda: Device or resource busy
> mdadm: /dev/sda has wrong uuid.
I'm guessing that /dev/sda contains your boot and root filesystems, and that
this isn't an error.
> mdadm: /dev/sdf is identified as a member of /dev/md0, slot 3.
> mdadm: /dev/sde is identified as a member of /dev/md0, slot 1.
> mdadm: /dev/sdd is identified as a member of /dev/md0, slot 2.
> mdadm: /dev/sdc is identified as a member of /dev/md0, slot 4.
> mdadm: /dev/sdb is identified as a member of /dev/md0, slot 0.
> mdadm: added /dev/sdb to /dev/md0 as 0
> mdadm: added /dev/sdd to /dev/md0 as 2
> mdadm: added /dev/sdf to /dev/md0 as 3
> mdadm: added /dev/sdc to /dev/md0 as 4
> mdadm: added /dev/sde to /dev/md0 as 1
> mdadm: /dev/md0 assembled from 2 drives - not enough to start the array.
> --- snip ---
Those slot numbers are *really* important.
> It seems that mdadm would be able to identify all five original components of
> my array, but later decides that it found only two of them, and therefore
> can't start the array. /proc/mdstat, at this point in time, shows the
> following:
>
> --- snip ---
> md0 : inactive sde[1](S) sdc[5](S) sdf[3](S) sdd[2](S) sdb[0](S)
> 7325687800 blocks super 1.2
> --- snip ---
>
> The (S) should indicate the component being marked as "spare", right (mdstat
> really should have a manpage with a short overview of the most commonly
> observed abbreviations, symbols and terms - I guess I'll volunteer if you
> don't tell me that's already documented somewhere)?
>
> Shall I just try "-A --force" and that's supposed to kick the array enough to
> start again? Or is there anything else you could and would recommend before
> resorting to that?
Yes, --assemble --force.
> One thing I forgot to mention is that I cannot guarantee that the order of the
> drives is still the same as it was in the old box (device node names for the
> component disks could have changed), but I'm convinced that's not a problem
> and I mention it only for the sake of completeness.
May I suggest getting an lsdrv [1] report, which will give you the serial numbers
of your disks versus the device assignments, for later reference. And again
after it's all running, for completeness.
> I have attached a file with the output of `mdadm -E` for each of the
> components for your viewing pleasure - thanks in advance for anyone's time and
> effort who's looking into this!
HTH,
Phil
[1] http://github.com/pturmel/lsdrv
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8G9A0ACgkQBP+iHzflm3BlUACcCoUX1YdI0vM/GmNITIRAXz5q
EsIAn3FDUd92X4CG8YPNWEpc/2AC/icG
=R2R2
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2012-01-06 13:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-13 8:27 What just happened to my disks/RAID5 array? Johannes Truschnigg
2011-09-13 11:37 ` Phil Turmel
2011-09-13 18:56 ` Johannes Truschnigg
2011-09-14 11:41 ` Phil Turmel
2011-09-14 18:17 ` Johannes Truschnigg
2011-09-14 19:19 ` Phil Turmel
2012-01-06 10:51 ` Johannes Truschnigg
2012-01-06 13:16 ` Phil Turmel [this message]
2012-01-06 13:46 ` Johannes Truschnigg
2012-01-06 14:51 ` Phil Turmel
2012-01-06 15:28 ` Johannes Truschnigg
2012-01-07 14:23 ` John Robinson
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=4F06F410.4070807@turmel.org \
--to=philip@turmel.org \
--cc=johannes@truschnigg.info \
--cc=linux-raid@vger.kernel.org \
/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).