4

I'm trying to diagnose a possible disk problem on my OSX machine: I heard some funny noises, so I decided to do a read test of the entire disk using dd.

A few months ago this worked: dd would run for a couple of hours to read 750 GB, and then quit with a message saying 'N bytes transferred in M seconds'

Today, dd runs for a couple of minutes, then terminates with the message 'Killed'. I can't find what causes this.

I'm using this command: dd if=/dev/disk1s2 of=/dev/null bs=1024k which should keep going until it runs out of blocks to read.

The system logs don't contain any information on this (no events recorded around the time that dd is killed).

What can I do to solve this?

Anthon
  • 79,293
Hobbes
  • 143
  • 3
    If a drive is making "funny noises" it's probably already dead. I assume that you are just trying to confirm this fact. I'd caution you slightly against playing with broken drives as they can cause excess power draw which can damage upstream components like your drive controller which may be much harder to replace. – msw Sep 18 '13 at 11:22

3 Answers3

5

If you can install smartmontools on your Mac, then run a selftest on the disk

smartctl -t long /dev/disk1

This will take a few hours. Then query the result with:

smartctl -a /dev/disk1
Martin von Wittich
  • 14,187
  • I did this, took about 2.5 h and found no errors. The Reallocated_Event_Count is at 1 and Raw_Read_Error_Rate is 7, doesn't seem too worrying. I also haven't heard any more noises from the drive. Currently running ddrescue to double-check. – Hobbes Sep 18 '13 at 17:11
  • I've found SMART selftests to be extremely reliable, so I'd say everything's fine with your disk :). It generally can't hurt to have backups nonetheless, though. – Martin von Wittich Sep 18 '13 at 17:40
4

Use ddrescue (via homebrew or macports) instead of dd which will try and recover from read errors and also log them 

ddrescue /dev/disk1s2 hdimage logfile
Matt
  • 8,991
-1

Running dd on a damaged drive is a very very bad idea. It will not help and is just further stressing the drive. Instead of dd make a backup of your data. If that fails, you know your drive is dead and if it doesn't at least you've backed up. If all you want to do is check, just use S.M.A.R.T as @Martin von Wittich suggested.

As to why it is being killed, the reason is probably the OOM killer. The dd you are launching will use quite a bit of memory and if you run out of RAM it will be killed by the OOM killer with the message killed.

terdon
  • 242,166
  • True, but in this case I'm not certain the drive is damaged. All I have is 5 seconds of the drive running slightly louder than normal. Backups have been taken care of. If I find a read error, I know there's an actual hardware problem. – Hobbes Sep 18 '13 at 17:19
  • 1
    @Hobbes all true, but dd is just not the way to go, that's what S.M.A.R.T is for. And your process is almost certainly being killed by the OOM killer, the killed is a dead give away. – terdon Sep 18 '13 at 17:20
  • I just ran dd again while keeping an eye on memory usage via Activity Monitor. The odd thing is that the system reports about 3 Gb free, and the dd process uses around 450 kb just before it is killed.
    Reading a bit more about dd, I realize now that I didn't unmount the disk before running dd. Perhaps that's the culprit?     – Hobbes Sep 19 '13 at 08:02
  • 1
    @Hobbes ah, in that case it does not sound like the OOM killer, no. Upon reflection, i couldn't be, I forgot that you were specifying bs=1024k. – terdon Sep 19 '13 at 15:08
  • ddrescue is the first thing I run when a drive is having issue as it serves as the backup and test. how does a backup or the long smart test stress a drive less? – Matt Oct 05 '13 at 09:13
  • @mindthemonkey running dd and saving the output makes a lot of sense. As you said, it is a backup and a test. What does not make sense, is running dd to test a failing drive while writing to /dev/null which is what the OP was doing. That is just a stress test for the drive which, if failing, would do more harm than good. – terdon Oct 05 '13 at 13:06