Re: [Bug-ddrescue] ddrescue very slow, and specific data to copy help.

[Felix Ehlermann]

Dear Andreas,

this might not help on your ddrescue issue directly but might solve your
resulting problem:

If you know the configuration of your array you can start the array without
relying on the superblock by using mdadm --build.
You can refer to the data of your other drives' superblocks (mdadm
--examine) to determine how you need to --build your array.

As you are most likely not in the possession of a backup I would recommend
that you create images of your array's disks before you try anything. mdadm
--build doesn't really do any sanity-checks, so it will start the array even
in a completely wrong configuration (e.g. using wrong raid level or wrong
blocksizes, etc.) - running fsck would then destroy mot of your data.
>From my experience mdadm works fine on loopback devices, so my usual
approach is to create a copy of each drive's image file and use these copies
for rebuilding the array, repairing the filesystem, etc. If anything goes
wrong I can easily make a new copy of the original image files and try
again.


Kind Regards
Felix

-----Ursprüngliche Nachricht-----
Von: address@hidden
[mailto:address@hidden Im Auftrag von
Andreas Boman
Gesendet: Dienstag, 7. Mai 2013 23:56
An: address@hidden
Betreff: [Bug-ddrescue] ddrescue very slow, and specific data to copy help.

Hi,

Sorry for writing the list not about a bug, I've been working on trying 
to solve this dilemma for several days now.

I've had ddrescue running for a few days trying to recover a disk that 
failed out of a linux md array.

The first pass ran with options -g -n (no -f version 1.11) ran very 
quickly (around 100 MB/s), seemed to recover around 600 GB or so before 
completing. I then started a second pass with options -d -r3. This was 
running around 32 MB/s and ran over night. In the morning it had 
recovered most of the disk, less some 7 GB, and was running at 512 B/s. 
This is the current status and has been for a few days, at this rate it 
will take over 160 days to finish the run. I've tried to run a few 
different options to speed it up.

I compiled version 1.17-rc3 from source to try to use --min-read-rate= 
to make it skip ahead, but that option seemed to do nothing (no 
skipping, no speedup).

This is what is currently running (time since last successful read has 
always been 0):

# ./ddrescue -f -d /dev/sdb /dev/sdf /root/rescue.log


GNU ddrescue 1.17-rc3
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:     1493 GB,  errsize:       0 B,  errors:       0
Current status
rescued:     1493 GB,  errsize:       0 B,  current rate:      512 B/s
    ipos:   946205 MB,   errors:       0,    average rate:      585 B/s
    opos:   946205 MB,    time since last successful read:       0 s
Copying non-tried blocks...


Currently I can live with this amount of data loss, however it looks 
like the md superblock has not been copied over to the new disk, 
although it is fine and readable on the old one, and I need that to 
restore the array with the new disk.

The md superblock (version 0.90.0) resides at the end of the partition 
last 128 K or so. I tried to use ddrescue --input-position= to copy the 
end of the disk and was stepping back to several hundred MB. Each 
ddrescue run like that completed without errors (very quickly) but I 
still cannot see a md superblock on the target disk.

I'm pretty sure I'm overlooking something or doing something silly here 
and would appreciate a smack with the clue stick from somebody.


Thank you,
Andreas
(please cc me as I'm not subscribed)

Partition information below:
-(address@hidden) fdisk -l /dev/sdb

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x3d1e17f0

    Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1      182401  1465136001   fd  Linux raid 
autodetect
-(~)-
-(address@hidden) fdisk -l /dev/sdf

Disk /dev/sdf: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x3d1e17f0

    Device Boot      Start         End      Blocks   Id  System
/dev/sdf1               1      182401  1465136001   fd  Linux raid 
autodetect
Partition 1 does not start on physical sector boundary.

_______________________________________________
Bug-ddrescue mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-ddrescue