Recover from read_dma errors?

dave

dave

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.
 
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.
 
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:

Code: 
...
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?
 
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?
Click to expand...

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.
 
Very helpful response, thanks. I am dumping /usr right now... I will post some info when I am done.
 
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.
 
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.
Click to expand...

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.
 
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.
 
You must log in or register to reply here.
Back
Top