From: Gimpbully <gimpbully@gmail.com>
To: Phil Turmel <philip@turmel.org>
Cc: Sam Bingner <sam@bingner.com>,
"<linux-raid@vger.kernel.org>" <linux-raid@vger.kernel.org>
Subject: Re: array went wonky
Date: Thu, 2 May 2013 07:18:29 -0700 [thread overview]
Message-ID: <CF52FDBB-A0DA-4912-9352-3A742BBC273B@gmail.com> (raw)
In-Reply-To: <15E1BF3C-2361-4FC7-8D19-AA319C187AF5@gmail.com>
This is very odd. When trying to force an assemble, it's syaing no superblock on /dev/sdf1, but the --examine output appears to say otherwise… Does anyone have any idea how to do this without doing a re-creation?
eduardo ~ # mdadm --examine /dev/sd{f,g,e,a}1 | egrep 'Event|/dev/sd'
/dev/sdf1:
Events : 25979
this 5 8 81 5 spare /dev/sdf1
0 0 8 33 0 active sync /dev/sdc1
2 2 8 65 2 active sync /dev/sde1
4 4 8 1 4 active sync /dev/sda1
5 5 8 81 5 spare /dev/sdf1
/dev/sdg1:
Events : 25971
this 1 8 17 1 active sync /dev/sdb1
0 0 8 33 0 active sync /dev/sdc1
1 1 8 17 1 active sync /dev/sdb1
2 2 8 65 2 active sync /dev/sde1
4 4 8 1 4 active sync /dev/sda1
5 5 8 81 5 spare /dev/sdf1
/dev/sde1:
Events : 25979
this 2 8 65 2 active sync /dev/sde1
0 0 8 33 0 active sync /dev/sdc1
2 2 8 65 2 active sync /dev/sde1
4 4 8 1 4 active sync /dev/sda1
5 5 8 81 5 spare /dev/sdf1
/dev/sda1:
Events : 25979
this 4 8 1 4 active sync /dev/sda1
0 0 8 33 0 active sync /dev/sdc1
2 2 8 65 2 active sync /dev/sde1
4 4 8 1 4 active sync /dev/sda1
5 5 8 81 5 spare /dev/sdf1
eduardo ~ #
On May 1, 2013, at 11:59 AM, Gimpbully <gimpbully@gmail.com> wrote:
> Alright, so I've ddrescued 2 disks now:
> sda - clean
> sdb - SMART errors, kicked out of array
> sdc - SMART errors, kicked out of array
> sde - ddrescued copy of sdb
> sdf - original failed disk, replaced. is now a ddrescued copy of sdc
>
> So I run
>
> eduardo ~ # mdadm --assemble --force /dev/md127 /dev/sd{f,g,e,a}1
> mdadm: cannot open device /dev/sdf1: Device or resource busy
> mdadm: /dev/sdf1 has no superblock - assembly aborted
> eduardo ~ #
>
> Any ideas?
>
> On Apr 30, 2013, at 7:48 AM, Gimpbully <gimpbully@gmail.com> wrote:
>
>> I have no intentions of recreating at all. I fully understand the implications (I've had stripe orders go bad on truly massive scales before, I don't ever wanna experience that again), I just don't know mdadm as well as other vendor storage.
>>
>> I was able to ddrescue a copy of sdb with no errors. I assembled the array and got a file system metadata dump (this is HUGE) and it's currently rebuilding before I even look at data. Thank you all for your help, patience was absolutely key here.
>>
>>
>> On Apr 30, 2013, at 7:45 AM, Phil Turmel <philip@turmel.org> wrote:
>>
>>> On 04/30/2013 02:20 AM, Sam Bingner wrote:
>>>> On Apr 29, 2013, at 4:33 PM, "Gimpbully" <gimpbully@gmail.com>
>>>> wrote:
>>>>> On Apr 13, 2013, at 7:20 AM, Sam Bingner <sam@bingner.com> wrote:
>>>>>
>>>>>> After that you can try to recreate the array with the proper
>>>>>> order (sdc1, sdb1, sde1, missing, sda1) and copy data off or add
>>>>>> the spare in again depending on if you were able to recover all
>>>>>> the data wih GNU ddrescue.
>>>>>
>>>>>
>>>>> What do you mean recreate? what's the specific command? something
>>>>> like:
>>>>> mdadm --create --assume-clean --level=5 --raid-devices=5 /dev/md127
>>>>> /dev/sdc1 /dev/sdb1 /sdv/sde1 missing /dev/sda1
>>>>
>>>> Don't recreate it - I said the wrong thing... You want to do an
>>>> assemble on them with force if possible... Recreate is last ditch and
>>>> make sure you have another copy if you do the previous command in
>>>> case it doesn't work right due to offsets etc...
>>>>
>>>> try:
>>>> mdadm --stop /dev/md127
>>>> mdadm --assemble --force /dev/md127 /dev/sd{c,b,e,a}1
>>>
>>> Yes.
>>>
>>>> If you DO need to recreate it, what you showed looks correct.
>>>
>>> NO!
>>>
>>> The OP has *not* shared sufficient information on the array members to
>>> say that. Since it has "worked for years", the odds of an offset error
>>> is *very* high. Chunk size defaults are also likely to be different.
>>>
>>> *Complete* output of "mdadm -E" for the array members is needed before
>>> any "--create" operation is attempted. Plus the distro info, kernel
>>> version, and mdadm version .
>>>
>>> Phil
>>
>
--
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
next prev parent reply other threads:[~2013-05-02 14:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-13 5:41 array went wonky Gimpbully
2013-04-13 14:20 ` Sam Bingner
2013-04-13 15:46 ` Robin Hill
2013-04-13 16:09 ` John White
2013-04-30 2:33 ` Gimpbully
2013-04-30 6:20 ` Sam Bingner
2013-04-30 14:45 ` Phil Turmel
2013-04-30 14:48 ` Gimpbully
2013-05-01 18:59 ` Gimpbully
2013-05-02 14:18 ` Gimpbully [this message]
2013-05-02 14:29 ` Gimpbully
2013-05-03 6:47 ` Gimpbully
2013-05-03 14:24 ` Phil Turmel
2013-05-03 7:40 ` Robin Hill
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=CF52FDBB-A0DA-4912-9352-3A742BBC273B@gmail.com \
--to=gimpbully@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=philip@turmel.org \
--cc=sam@bingner.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).