From: Wols Lists <antlists@youngman.org.uk>
To: thomas@fjellstrom.ca
Cc: linux-raid@vger.kernel.org
Subject: Re: Re-add not selecting drive for correct slot?
Date: Mon, 10 Aug 2015 19:10:55 +0100 [thread overview]
Message-ID: <55C8E92F.5020700@youngman.org.uk> (raw)
In-Reply-To: <2248170.b8F2naoiGF@balsa>
On 10/08/15 18:44, Thomas Fjellstrom wrote:
> On Mon 10 Aug 2015 11:35:13 AM Mikael Abrahamsson wrote:
>> On Sat, 8 Aug 2015, Thomas Fjellstrom wrote:
>>> I did try that :( It fails to assemble because it only sees sdc as a
>>> spare.
>>> Maybe because I did things with the old mdadm first, and did a --remove?
>>> That seems to have wiped out the "slot" information (it's -1) so the
>>> assemble force magic can't figure things out? Just a guess on my part.
>>
>> Unless someone else has a better idea, I'd say you're right. If you would
>> have unplugged the failed drive (so it disappeared completely), it could
>> probably have been re-added. So unless you have a copy of the old
>> superblock, your only way to proceed now is to use --create --assume-clean
>> and get all the parameters right (order, offsets etc). There are lots of
>> examples in the mailing list archives of people trying this and some
>> actually suceeding.
>
> I think the only thing that would stop that from working is that there is data
> in the bitmap. So if a assume clean is done, it might ignore that and cause
> some extra corruption?
Which is why you use loopback devices. You'll need to look back at
previous posts to see how to do it, but you put a pseudo-layer over the
real disks (which never actually get written to), and you can then fsck
your array. If that comes up clean, you know you got the assemble
parameters right, and you can shut down the pseudo-array and assemble
the real array.
>
> It'd be interesting to figure out if i can set that slot number manually or
> with a tool. That might be a smarter/safer way of doing it.
>
Better the pseudo way (which will definitely allow you to recover IF the
disk isn't corrupted) than trying your own stuff which might write to
the disk and make life harder/impossible to recover.
Cheers,
Wol
next prev parent reply other threads:[~2015-08-10 18:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-07 5:09 Re-add not selecting drive for correct slot? Thomas Fjellstrom
2015-08-07 12:38 ` Mikael Abrahamsson
2015-08-08 2:17 ` Thomas Fjellstrom
2015-08-08 6:11 ` Mikael Abrahamsson
2015-08-08 17:29 ` Thomas Fjellstrom
2015-08-10 9:35 ` Mikael Abrahamsson
2015-08-10 17:44 ` Thomas Fjellstrom
2015-08-10 18:10 ` Wols Lists [this message]
2015-08-10 18:42 ` Thomas Fjellstrom
2015-08-25 18:18 ` Thomas Fjellstrom
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=55C8E92F.5020700@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=linux-raid@vger.kernel.org \
--cc=thomas@fjellstrom.ca \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.