From: Thomas Fjellstrom <thomas@fjellstrom.ca>
To: Wols Lists <antlists@youngman.org.uk>
Cc: linux-raid@vger.kernel.org
Subject: Re: Re-add not selecting drive for correct slot?
Date: Mon, 10 Aug 2015 12:42:35 -0600 [thread overview]
Message-ID: <65422527.2R17mF7xfV@balsa> (raw)
In-Reply-To: <55C8E92F.5020700@youngman.org.uk>
On Mon 10 Aug 2015 07:10:55 PM Wols Lists wrote:
> 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.
Yeah, I did that once previously for a recovery. It was quite handy. I backed
everything up to a different machine. And re-created the array.
I may do that again. But then I actually have a mostly full backup, about the
only things i care about is some pictures I added to the array before it went
down, that I still have a copy of, but would have to copy them all back off of
various devices.
> Cheers,
> Wol
--
Thomas Fjellstrom
thomas@fjellstrom.ca
next prev parent reply other threads:[~2015-08-10 18:42 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
2015-08-10 18:42 ` Thomas Fjellstrom [this message]
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=65422527.2R17mF7xfV@balsa \
--to=thomas@fjellstrom.ca \
--cc=antlists@youngman.org.uk \
--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 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.