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: [email protected] [mailto:[email protected]] Im Auftrag von Andreas Boman Gesendet: Dienstag, 7. Mai 2013 23:56 An: [email protected] 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: -(root@yggdrasil) 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 -(~)- -(root@yggdrasil) 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 [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
