Bad blocks? badblocks!
There are not many things I miss from Mac OS 9. But there’s one that was really useful: the ability to test a hard drive surface. OS 9 disk formatter (I don’t even recall it’s name) had a “Test Disk” option that would perform a surface scan of the selected hard drive. That was awsome to test for bad blocks on the drives.
Unfortunately, that’s impossible to do with Mac OS X, at least with it’s built-in software. There are some commerical applications to do that (like TechTool Pro), but I get a little pissed off when I have to spend a lot of money buying a software that does a zillion things when all I want is surface scans, and specially when I could do it with the “old” OS and not with the new powerful UNIX-based one.
Well, Linux has the badblocks command that will do just that: test the disk surface for bad blocks. It’s a simple UNIX command, so I thought there must be a port of that to OS X (and, of course, I could try to compile it in OS X as last resource). After some googling, I found out badblocks is part of the ext2fs tools. And, fortunately, Brian Bergstrand has already done the port to OS X, including a nice installer.
The installer installs all the ext2fs stuff, including an extension that will allow you to access ext2fs volumes on OS X. As always, this is a somewhat risky operation. Personally, I avoid as many extensions as I can, because they run too close to the kernel for me to feel confortable. So, if possible, install it on a secondary OS (like an utility/recover system on an exteral hard drive, or so).
The badblocks command will be installed in /usr/local/sbin/badblocks, and it will probably not be on your PATH, so you have to type the entire path when using, or edit your PATH environment variable.
Usage is simple. First, run the “mount” command, so that you know the device names for the drives you want to test. You can obtain something like this:
arroz% mount
/dev/disk0s3 on / (local, journaled)
devfs on /dev (local)
fdesc on /dev (union)
automount -nsl [142] on /Network (automounted)
automount -fstab [168] on /automount/Servers (automounted)
automount -static [168] on /automount/static (automounted)
The internal hard drive is /dev/disk0 (note that /dev/disk0 is the entire drive, /dev/disk0s3 is a single partition). Imagining you want to test the internal hard drive you would type the command (as root):
badblocks -v /dev/disk0
This would start a read-only test on the entire volume. The -v is the typical verbose setting, so you may follow what’s happening. This will take a long time, depending on the hard drive you use. For a 160 GB hard drive, it took between 2 and 3 hours in a G5 Dual 2 Ghz.
I mention this because time is an important factor when testing hard drives! You should run badblocks on a known-to-be-in-good-condition hard drive, so that you can get the feeling of how fast (or slow) badblocks is. Later, if you test a possibly failing hard drive, and badblocks progresses notably slower, it will probably mean that the hard drive is in bad condition (even if it doesn’t have badblocks).
After running the command, you may get two results: your disk has, or hasn’t badblocks! 
You will see many outputs of a successful surface scan, so I leave here an example of a not-so-successful one:
/usr/local/sbin arroz$ sudo ./badblocks -v /dev/disk0
Password:
Checking blocks 0 to 156290904
Checking for bad blocks (read-only test): 120761344/156290904
120762872/156290904
120762874/156290904
done
Pass completed, 3 bad blocks found.
This is the result of a test on a 160 GB hard drive with 3 bad blocks.
After getting something like this, you may try to run badblocks again, in write mode. Note that this will destroy all the information you have on the hard drive! badblocks won’t copy the information to memory, and than back to disk. It simple destroys it. The point of running a write-enabled badblocks check is forcing the hard drive to remap the damaged sectors. Hard drives have a reserved space to use when bad blocks are found. The bad blocks are remapped to that reserved space, until it fills. And this will only happen on a write. So, run badblocks in write mode, and then again in read-only mode. If badblocks finds no bad blocks, your hard drive is fine (for now). If badblocks still finds bad blocks, it means that there are so many damaged blocks on the disk surface that the reserved area is full. Forget it, and throw the disk away. It’s useless.
July 17th, 2007 at 11:42 am
The good old memories of Drive Setup in Mac OS 9, where we used it to ‘Initialiaze’ disks…
August 3rd, 2007 at 12:03 pm
I want to reinforce the “time is an important factor when testing hard drives” statement I did on this post. Some days ago I helped a colleague that was having severe speed problems with his Powerbook. By looking arround, it was easy to conclude that the hard drive was the culprit. The log was full of I/O errors. I run badblocks on it, and it was terribly slow. So, I canceled the scan, and restarted only for the first 50000 blocks. Testing 50000 blocks should take no more than 5 or 10 seconds, depending on the hard drive speed. On the problematic drive, it took more than 5 minutes… but no bad block was detected! So, keep this is mind: speed is important when testing hard drives. Hard drives may suffer from a lot of mechanical or electronic problems, not just errors in the disk surface.
September 4th, 2007 at 10:22 am
Be careful running read-only utilities. As Miguel mentions in the comment above, merely being able to read every block from the drive does not necessarily mean the hard disk is OK.
Beware TechToolPro (version 4.5.3 and previous versions at least, I’m hoping they will fix future versions soon), as it simply does a Read test of the hard disk blocks. Many faulty drives pass TTP’s tests, even though I know them to be faulty. The drives never pass OS 9 Norton Disk Doctor’s Read/Write/Verify sector scan. It’s a shame that no OS X utility currently has the same functionality.
I’m dying to find an application that performs speed-related hard disk block-testing. Some Windows products have this functionality.
February 15th, 2008 at 5:10 am
How do you tell badblocks to do a write test?
February 15th, 2008 at 6:20 am
Greenie says: “The drives never pass OS 9 Norton Disk Doctor’s Read/Write/Verify sector scan.”
Norton Disk Doctor for OS 9 doesn’t do writes during its surface scan, unfortunately. I don’t think Norton Disk Doctor for OS X does either.
One of the best OS 9 utilities that I can remember, for which you could set its prefs to do a continuous read/write test of a drive (which was nondestructive as well, writing the data back to the blocks–nice!) was FWB Hard Disk Toolkit’s “Device Test” option. There were maybe a couple other utils that could do this, but that’s the only one I can remember at the moment. I can’t find an OS X utility that can do this, though there may be one.
February 15th, 2008 at 7:47 am
John:
With the options -w or -n. Quoting the badblocks man page:
-n Use non-destructive read-write mode. By default only a non-
destructive read-only test is done. This option must not be
combined with the -w option, as they are mutually exclusive.
-w Use write-mode test. With this option, badblocks scans for bad
blocks by writing some patterns (0xaa, 0×55, 0xff, 0×00) on
every block of the device, reading every block and comparing the
contents. This option may not be combined with the -n option,
as they are mutually exclusive.
Note that -w destroys all your information, -n tries not to (unless there’s a power cut or something).
February 15th, 2008 at 3:40 pm
Thanks, Miguel. I haven’t installed badblocks yet, and wanted to know if it had write capabilities before doing so.
April 17th, 2008 at 6:27 pm
A correction to my correction above: pre-X versions of Norton Utils (don’t know about the OS X version) DO have an option to do a read/write/verify test on hard drives, and have options to either fix files with bad blocks, or to leave them alone. What this fix entails, I don’t know, but I think it may write bad blocks out of the drive’s directory, then create pointers to new blocks, which it fills with zeros.
It’s been a while since I’ve changed Norton Utils’ prefs to do a read/write/verify–I prefer its read-only test, since I don’t know whether to trust its bad block repair option–so I’d forgotten it was there, until I happened to check for it today.
May 6th, 2008 at 3:02 pm
Hi,
as I had to find out, Brian’s port does officially NOT support 10.4 or 10.5 - which makes it rather confusing/senseless in today’s Mac OS X to use these tools.
However it might be that badblocks does work fine - but there is no guarantee.
So, I actually installed it and ran into another problem under 10.5. - which now might be a consequence of the lack of support for 10.5 :
MacBook-20:sbin peterpan$ sudo ./badblocks -w /dev/disk1
./badblocks: Resource busy while trying to open /dev/disk1
Any suggestions?
br
Peter from Vienna, AT
May 6th, 2008 at 4:09 pm
Hi!
I never actually used this to mount ext2 volumes, so I have no idea if it works fine. Anyway, badblocks seems to work in every machine I tried it, Tiger or Leopard, PowerPC or Intel.
About your problem, apparently you are doing a write-test (which is destructive, be careful!) on a disk that is being used (probably it has mounted partitions). Everytime I saw that message was because the disk was being used, so it could not be tested. That doesn’t indicate an incompatiblity between the OS and badblocks.
Yours
Miguel Arroz