All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Klauer <Andreas.Klauer@metamorpher.de>
To: Paul Tonelli <paul@tonel.li>
Cc: linux-raid@vger.kernel.org
Subject: Re: Recovery after accidental raid5 superblock rewrite
Date: Sun, 4 Jun 2017 01:29:19 +0200	[thread overview]
Message-ID: <20170603232919.GA17108@metamorpher.de> (raw)
In-Reply-To: <12fc0496-423a-bca6-ac57-ed40958645e7@tonel.li>

On Sun, Jun 04, 2017 at 12:33:43AM +0200, Paul Tonelli wrote:
> I am still searching for a way to put a complete block device (/dev/sdX) 
> read-only for these tests, I believe using overlays is the solution.

Yes.

Overlays are extremely useful for data recovery.

It is unfortunate there is no standard tool to manage them easily.
The "overlay functions" in the wiki come close but people don't find 
out about it until it's too late.

> Actually, this is one question I have: with mdadm, creating a raid5 with 
> two disks and then growing it to 3 creates exactly the same structure as 
> creating directly a 3 disk raid5 ? Your message seems to say it is the 
> same thing.

Good catch. It would probably move the data offset.

# truncate -s 3TB a b c
# mdadm --create /dev/md42 --level=5 --raid-devices=2 /dev/loop[01]
# mdadm --examine /dev/loop0
    Data Offset : 262144 sectors
# mdadm --grow /dev/md42 --raid-devices=3 --add /dev/loop2
# mdadm --examine /dev/loop0
    Data Offset : 262144 sectors
     New Offset : 260096 sectors

So on re-create you have to find and specify the correct --data-offset.

How to determine the correct data offset? See if you can find LVM magic 
string "LABELONE" in the first 256MiB of the two disks you didn't 
dd-overwrite. That minus 512 bytes should be the correct offset.

# hexdump -C /dev/some-pv
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  4c 41 42 45 4c 4f 4e 45  01 00 00 00 00 00 00 00  |LABELONE........|
00000210  55 87 20 ff 20 00 00 00  4c 56 4d 32 20 30 30 31  |U. . ...LVM2 001|

If unlucky it just happened to be in the drive you overwrite. 
In that case you have to xor the two others.

> Is it possible to copy only a raid superblock from one disk to another 
> directly using dd ?

Each superblock is unique (differs in device role and checksum at minimum). 
So copying superblocks usually is not a thing. Even copying drives can 
result in a mess (UUIDs are no longer unique, you have little / no control 
which drive will actually be used). This is also a problem you might 
encounter with overlays in conjunction with autoassembly/automount magicks 
that might be running in the background.

Regards
Andreas Klauer

  reply	other threads:[~2017-06-03 23:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-03 19:46 Recovery after accidental raid5 superblock rewrite Paul Tonelli
2017-06-03 21:20 ` Andreas Klauer
2017-06-03 22:33   ` Paul Tonelli
2017-06-03 23:29     ` Andreas Klauer [this message]
2017-06-04 22:58       ` Paul Tonelli
2017-06-05  9:24         ` Andreas Klauer
2017-06-05 23:24           ` Paul Tonelli
2017-06-05 23:56             ` Andreas Klauer
2017-06-10 20:04               ` Paul Tonelli
2017-06-10 20:41                 ` Andreas Klauer
2017-07-31 19:57                   ` Paul Tonelli
2017-07-31 20:35                     ` Wols Lists
2017-08-01 14:01                     ` Phil Turmel

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=20170603232919.GA17108@metamorpher.de \
    --to=andreas.klauer@metamorpher.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=paul@tonel.li \
    /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.