# Recover from read_dma errors?



## dave (Feb 12, 2011)

I have a system that has begun to show read_dma errors for the boot drive.  It will not mount /usr and so only boots to single user mode.  This may be a silly question, but....  Will I be able to use *dd* to copy to a new drive, or will I have to reinstall FreeBSD on the new drive and restore configs?  What is the best way to recover from this?  Thanks.


----------



## wblock@ (Feb 12, 2011)

Check data and power cables to the drive first.  If it's really a drive surface problem, *dd* won't be able to read it either.  But it might be just certain bad spots, and the noerror,sync options to *dd* might be able to get some of the data back.  For that matter, dump(8) may be able to copy some of the unmounted filesystem.


----------



## dave (Feb 12, 2011)

So I sat down to begin work on this machine today, and it booted in to multi-user.  I was able to run fsck, and received the exact same 2 read_dma errors as yesterday:


```
...
ad0: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=214589599

CANNOT READ BLK: 207746528
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? [yn] y

ad0: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=1<ILLEGAL_LENGTH> LBA=214589625
THE FOLLOWING DISK SECTORS COULD NOT BE READ: 207746554,

** Phase2 - Check Pathnames
...
```

Does this mean I can use *dd* with sync and noerror?  Can I use any new replacement drive as long as it is same or larger size?


----------



## wblock@ (Feb 12, 2011)

dave said:
			
		

> So I sat down to begin work on this machine today, and it booted in to multi-user.  I was able to run fsck, and received the exact same 2 read_dma errors as yesterday:
> ...
> 
> Does this mean I can use *dd* with sync and noerror?  Can I use any new replacement drive as long as it is same or larger size?



Yes, you probably can use *dd*.  I'd still use *dump*, because it will only copy used blocks, and you'll be able to restore it to filesystems of different sizes than the original.  See Backup Options For FreeBSD for some information; I should add an example of dumping from one filesystem and piping that direct into restore.

If you use *dd*, the replacement drive has to be at least as big as the original.  Beware that a lot of bigger new drives have 4K sectors.  If you don't get the partitions lined up right, they'll work but be very slow.  And with *dd*, you don't get any options on where they go, they have to be the same as the original.


----------



## dave (Feb 12, 2011)

Very helpful response, thanks.  I am dumping /usr right now...  I will post some info when I am done.


----------



## wblock@ (Feb 12, 2011)

Just updated the backup article to show a specific example of copying filesystems.  Proofread, but I added the subshell use to cut down on the noise of changing into and out of the target directories.  Tested a little, but be cautious, and please let me know if you find mystaiks.


----------



## Beastie (Feb 12, 2011)

Dumping the partitions should work. I recently did that on a disk with at least 40 bad sectors spread everywhere, including some of the /boot/kernel/* files. It died hours later. The dump files were restored successfully.


----------



## wblock@ (Feb 12, 2011)

Beastie said:
			
		

> Dumping the partitions should work. I recently did that on a disk with at least 40 bad sectors spread everywhere, including some of the /boot/kernel/* files. It died hours later. The dump files were restored successfully.



*dump* is pretty cool.  The man page says it'll handle 32 disk read errors without operator interaction.  It should show warnings about them, though.


----------



## dave (Feb 16, 2011)

It works out that I was unable to save the /usr partition with dump.  The longer dump ran, the more read_dma errors appeared.  It became obvious I was losing the drive faster than I was saving it.  I installed a new drive and that was OK because I just had to rebuild and restore a few configs (I had tarred up copies of /etc, /usr/local/etc, and my home dir handy).  All data was fine as that was stored on separate, mirrored, drives.  I have learned my lesson though.  I will mirror that new OS drive with gmirror and periodically use dump to back it up.


----------

