Do you have a Mac that beach balls (colourful pinwheels that produce colourful language) for 30-60 seconds at a time when you’re not running a computationally intensive task? Your hard drive could be dying. I hope you’re backing up. But I’m not writing this blog post to convince you that backing up your data regularly is a good idea (but it is, though). Instead, I’m going to show you how to see if that is indeed what is causing the beach balling and, if so, how to keep on tempting fate by keeping your failing hard drive chugging along while reducing your unwanted trips to the beach ((Is it any wonder why computer scientists tend to be so pasty?))
I’m sure many of you know from my previous blog posts that I have a MacBook Air. Not one of those fancy ones with an SSD drive. It’s one of the less-expensive older models with a tiny (read: fragile) 1.8″ drive with a roulette wheel for a storage medium. It’s out of warranty, but I’m not about to find a replacement hard drive. A) it’s not really my computer (it’s Steve’s), B) getting a whole new — and faster — MacBook Air isn’t that much more expensive, and, most importantly, C) I want to avoiding sending things to the landfill (and digging up new, exotic materials). So my hard drive rolled double-zeros a few months ago and every few minutes, my computer would inexplicably lock up for about a minute. Since it’s embarrassing doing demos and giving presentations with a computer that locks up that frequently, here’s what I did (so as to avoid having to buy a computer before going to VLHCC, which is where I am now):
Step 1: Determine if a dying hard drive is your problem: Keep a Terminal window open (/Applications/Utilities). Right after your computer locks up, go to the Terminal window and type
sudo dmesg[enter]
And then enter your password (you shouldn’t see characters while you type). Next, look for something that looks like the following near the bottom of the screen:
disk0s2: I/O error.
0 [Level 3] [ReadUID 0] [Facility com.apple.system.fs] [ErrType IO] [ErrNo 5] [IOType Read] [PBlkNum 119607472] [LBlkNum 7686] [FSLogMsgID 1231851811] [FSLogMsgOrder First]
0 [Level 3] [ReadUID 0] [Facility com.apple.system.fs] [DevNode /dev/disk0s2] [MountPt /] [Path /private/var/folders/tc/f4z9ks_15qn3j2mjdhzv51n00000gr/C/com.apple.Safari/SafeBrowsing.db] [FSLogMsgID 1231851811] [FSLogMsgOrder Last]
Congratulations! You have found surprise alligators and your disk is dying (in my case, disk0s2 — my laptop hard drive), which means we can at least keep the beach balls at bay for now ((Alligators love beaches, so this might help with the surprise alligators, too)). The second bolded bit above (Path blah blah blah) tells you what file lies in the path of destruction.
Step 2 (optional): You could try to make a copy of the failing file (although that will probably fail, unless you’re lucky). But you have backups, right?
Step 3: The file lies on a part of the disk that has physically failed. We don’t want to use that space for anything that we care about. So rename the file. It’s already lost. Now, its dead body will take up space and serve as a warning to other files to stay away.
Step 4: Restore the file from your backups. We DID establish that you have backups. In any event, do not delete the dead file. You shouldn’t even bother trying to resuscitate it at this point.
Step 5: Keep playing with fire. Your computer should beach ball slightly less. Hurrah! You have cheated death for now.
Step 6: Back up. Oh, right. I wasn’t going to proselytize. But, really. BACK UP YOUR FILES! You caught a lucky break. Your hard drive really is on the brink. If you’ve got an Intel Mac, treat yourself to Snow Leopard for $29, an external hard drive, and make a Time Machine backup. It’s really quite simple (you may need to exclude the dead file from backups, though).