Thread (2 messages) 2 messages, 2 authors, 2007-04-13

Re: Manually hacking superblocks

From: David Greaves <hidden>
Date: 2007-04-13 10:23:28

Lasse Kärkkäinen wrote:
I managed to mess up a RAID-5 array by mdadm -adding a few failed disks
back, trying to get the array running again. Unfortunately, -add didn't
do what I expected, but instead made spares out of the failed disks. The
disks failed due to loose SATA cabling and the data inside should be
fairly consistent. sdh failed a bit earlier than sdd and sde, so I
expect to be able to revocer by building a degraded array without sdh
and then syncing.

The current situation looks like this:
      Number   Major   Minor   RaidDevice State
   0     0       8       33        0      active sync   /dev/sdc1
   1     1       0        0        1      faulty removed
   2     2       8       97        2      active sync   /dev/sdg1
   3     3       8      129        3      active sync   /dev/sdi1
   4     4       0        0        4      faulty removed
   5     5       8       81        5      active sync   /dev/sdf1
   6     6       0        0        6      faulty removed
   7     7       8      177        7      spare
   8     8       8      161        8      spare
   9     9       8      145        9      spare

... and before any of this happened, the configuration was:

disk 0, o:1, dev:sdc1
disk 1, o:1, dev:sde1
disk 2, o:1, dev:sdg1
disk 3, o:1, dev:sdi1
disk 4, o:1, dev:sdh1
disk 5, o:1, dev:sdf1
disk 6, o:1, dev:sdd1

I gather that I need a way to alter the superblocks of sde and sdd so
that they seem to be clean up-to-date disks, with their original disk
numbers 1 and 6. A hex editor comes to mind, but are there any better
tools for that?
You don't need a tool.
mdadm --force will do what you want.

Read the archives and the man page.

You are correct to assemble the array with a missing disk (or 2 missing disks
for RAID6) - this prevents the kernel from trying to sync. Not syncing is good
because if you do make a slight error in the order, you can end up syncing bad
data over good.

I *THINK* you should try something like (untested):
mdadm --assemble /dev/md0 --force /dev/sdc1 /dev/sde1 /dev/sdg1 /dev/sdi1
missing /dev/sdf1 /dev/sdf1

The order is important and should match the original order.
There's more you could do by looking at device event counts (--examine)

Also you must do a READ-ONLY mount the first time you mount the array - this
will check the consistency and avoid corruption if you get the order wrong.

I really must get around to setting up a test environment so I can check this
out and update the wiki...

I have to go out or a couple of hours. Let me know how it goes if you can't wait
for me to get back.

David
-
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help