Bienvenido! - Willkommen! - Welcome!

Bitácora Técnica de Tux&Cía., Santa Cruz de la Sierra, BO
Bitácora Central: Tux&Cía.
Bitácora de Información Avanzada: Tux&Cía.-Información
May the source be with you!

Thursday, June 9, 2011

dmraid disk failure - howto rebuild new disk

gparted do it?
Source
My Seagate drives are dropping like flies with less than 1400 hours of run time. (that's less than 58 days of service!) Latest is a 750G (ST3750330AS) that was part of the second raid set on one of my boxes. Seagate sent a new one and now I am trying to figure out how to rebuild the array. The fakeraid setup is with a nvidia bios raid chip using software dmraid. The array is composed of
/dev/sdb and /dev/sdd which are both part of /dev/mapper/nvidia_fffadgic:
[00:59 ecstasy:/home/david] # dmraid -r
/dev/sdd: nvidia, "nvidia_fffadgic", mirror, ok, 1465149166 sectors, data@ 0
/dev/sdc: nvidia, "nvidia_fdaacfde", mirror, ok, 976773166 sectors, data@ 0
/dev/sdb: nvidia, "nvidia_fffadgic", mirror, ok, 1465149166 sectors, data@ 0
/dev/sda: nvidia, "nvidia_fdaacfde", mirror, ok, 976773166 sectors, data@ 0
/dev/sdd failed and has been replaced. The partition information on /dev/sdb is:
[00:43 ecstasy:/home/david] # fdisk -l /dev/sdb
Disk /dev/sdb: 750.1 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 1 7553 60669441 5 Extended
/dev/sdb5 * 1 2432 19534977 83 Linux
/dev/sdb6 2433 2447 120456 83 Linux
/dev/sdb7 2448 7310 39062016 83 Linux
/dev/sdb8 7311 7553 1951866 82 Linux swap / Solaris
/dev/sdd is blank. My first thought was simply to use fdisk to create the extended partition /dev/sdd1 and then use the gparted-live CD to copy sdb[5 6 7 8] over to sdd and be done. The setup in gparted went fine, but when gparted went to format the partitions as ext3, it gave an error and would not go any farther. The error was simply a generic "operation could not be completed..." with nothing to say why. I don't know, but maybe it has something to do with both drives being combined under the device mapper heading of nvidia_fffadgic that caused it to puke.
That's pretty much where I am now. My next thought is to just use dd to copy the partitions over. I have opensuse on the sda/sdc array (mapper nvidia_fdaacfde), so the drives I am working with are not mounted anywhere and should be easy to work with.
What says the brain trust? Can you think of any way I was screwing up gparted so it wouldn't even format the copy partitions? What about the dd method?
 --------------
       dd bs=100M conv=notrunc if=/dev/sdb of=/dev/sdd
---------------
I did not read your first post with issue, but the above dd command is almost certainly wrong, but you won't have an issue unless you have an i/o error.
You need to use "conv=noerror,sync" and you want the block size to be 4k.
I believe notrunk will fill the remainder of the disk with zeros after the first error. Very bad. Think about a single media error early in the drive.
"noerror, sync" will fill the current block with zeros.
So with a 4k block you are doing the best kernel can provide (at least via dd.)
i.e. the kernel itself uses 4k blocks.
With a 100M block, if you have a i/o error you are going to blast a huge hole in the middle of your data.

No comments: