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.
The good old memories of Drive Setup in Mac OS 9, where we used it to ‘Initialiaze’ disks…
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.
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.
How do you tell badblocks to do a write test?
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.
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).
Thanks, Miguel. I haven’t installed badblocks yet, and wanted to know if it had write capabilities before doing so.
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.
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
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
I installed badblocks using portutil. I’m certain this is considered compatible with Leopard.
Hey, Peter Pan: It is possible that you still had the volume mounted. Badblocks will refuse to run on a mounted filesystem unless the -f option is specified (which I definitely don’t recommend: Just unmount it first).
the other option (Apple option) is to format the drive and check the option “zero data”, but sometimes you can´t that in which case the badblock is a good solution
Peter Pan: the drive is probably mounted, and you need to unmount before using.
I had to force the umount command:
umount -f /Volumes/disk
I have downloaded EXTfsManager because I think my hard drive has bad blocks. I am using Leopard . When I open EXTfsManager in system preferences, and select my hard drive, the mount and info options are greyed out! I cannot test my hard drive. If the program does not work, can someone please point me in the right direction of another program to test bad blocks? Thanks
You cannot run badblocks using the UI, you have to do as I describe, using the command line.
For those who are worried, badblocks works with ANY filesystem including HFS+.
However, if you are checking a drive for bad blocks formatted with ext2 or ext3, it is recommended that you use the e2fsck command instead with the -c option for a read ONLY test (or the -c -c option for a non destructive read/write test).
Bottom line: for all other filesystems (including HFS or HFS+) just use badblocks.
INSTALLATION:
Using fink or MacPorts is probably the easiest way to install badblocks plus all the other ext2fs tools. Or you can extract the following from the ext2fs tools package (from http://sourceforge.net/projects/ext2fsx/) and JUST install Badblocks and its libraries. Make sure you are logged into an Administrator account. I prefer this approach since it does NOT install the buggy ext2 filesystem driver.
Step 1 – Copy badblocks (You can install this anyway. But /usr/local/sbin is probably the best place. If you want to run it from any directory make sure /usr/local/sbin is in your PATH).
sudo cp badblocks /usr/local/sbin
Step 2 – Copy Supporting Libraries (libext2fs.2.1.dylib and libcom_err.1.1.dylib) into /usr/local/lib
sudo cp libext2fs.2.1.dylib /usr/local/lib
sudo cp libcom_err.1.1.dylib /usr/local/lib
Step 3 (Optional) — Copy badblocks man page to /usr/local/share/man/man8
sudo cp badblocks.8 /usr/local/share/man/man8
NOTE: You may need to create the /usr/local/share/man/man8 directory. And you should check to see whether the /usr/local/share/man directory is in your MANPATH. It should be by default.
HOW TO USE:
For drives larger than 1 GB (i.e. the majority of drives), I recommend invoking badblocks as follows for a READ ONLY test:
sudo /usr/local/sbin/badblocks -b 4096 -c 32768 -v -s -o ~/Desktop/badblocks.txt /dev/diskX
NB — CHANGE X in /dev/diskX to the DISK NUMBER you want to check. Use the Mount command as recommended above to find the drive number.
-b sets the block size to 4096 (or 4KB) which is the default size for HFS+ disks greater than 1 GB in size. (If omitted, the default will be 1024 (or 1 KB). badblocks will still run fine but the block numbers will be meaningless).
-c sets the number of blocks that will be tested at a time. The default is 64. Setting a higher value will make the test run faster. Just make sure you have enough RAM. The amount of RAM in bytes used is the -b value multiplied by the -c value. The above settings use 128 MB of RAM.
-v turns on verbose mode.
-s Shows the progress of the scan by writing out the block numbers as they are checked
-o Writes the list of bad blocks to the specified file. Without this option, badblocks displays the list on its standard output.
If you see bad blocks in the badblocks.txt file, run badblocks again but add the -n option for a non-destructive read/write test. You can only do this is the drive is NOT mounted. If you are trying to run badblocks this on your internal Macintosh HD Start Up disk, you will need to reboot from an external disk with Mac OS X installed. (e.g. a bootable external disk made using the free Carbon Copy Cloner and run the “umount” and “badblocks” commands from the external disk).
There is also the -w option for a DESTRUCTIVE read/write test. This will destroy your data. But I recommend you NEVER use this option. It is better to reformat and ZERO out your data using Disk Utility. (see below for why). But note ALL YOUR DATA WILL BE LOST.. BACKUP FIRST..
If you are NOT worried about data loss, another option is to reformat your hard disk with suspected bad blocks and then ERASE it using the ZERO OUT option (using the Mac Disk Utility that comes with Mac OS X). This is the BEST approach to fix bad block errors since any bad blocks that cannot be remapped by the disk drive itself should be added to the Bad Blocks list in the HFS filesystem. Yes HFS (like other filesystems such as ext2 and ext3) also keep a list of bad blocks to avoid if the disk drive is unable to remap them. (This typically happens if the special reserved area of the disk drive is FULL).
IMPORTANT: I agree with Miguel if the special reserved area is FULL on the disk drive, it is best to throw out the drive since the drive cannot automatically remap bad sectors to this special reserved area. The HFS+ filesystem will NOT automatically remap sectors that were once good and are now bad. You will need to reformat and ZERO out the data to get the HFS+ filesystem to update its BAD BLOCK list.
NOTE: Unlike other filesystems (like ext2 and ex3), there is not way to import the list of bad blocks generated by the badblocks command into this list of bad blocks kept by the HFS+ filesystem. I wish Apple provided an easy way to do this but it does NOT. It is best to reformat and ZERO out the data as recommended by Apple. And then PRAY. :-)
I forgot to add that if you know where the bad blocks are located, you can try to write zeros to just these blocks to force the drive to remap these bad blocks to the special reserved GOOD area on the drive (assuming it is not full) using the dd command.
IMPORTANT: Writing zeros will cause data loss if a file is using any of these bad blocks. Duh! :-) If you are trying to recover data on bad blocks use the GNU ddrescue command (or one of the Mac file recovery programs like Data Rescue III).
For example, if the bad block is located at 2269012 on a HFS+ drive with a 4KB block size (i.e. any HFS+ formatted drive greater than 1 GB with have this block size), run these commands to write a ZERO on this bad block:
sudo dd if=/dev/zero of=/dev/hda3 bs=4096 count=1 seek=2269012
sudo sync
But if the special reserved area on the drive is FULL, you will be out of luck. dd is a low level command that is filesystem independent. It will NOT write to the HFS+ list of bad blocks (which is used when the drive is unable to remap bad blocks). In this case, you will need to reformat your drive and write zeros to the WHOLE drive using disk utility.
How do I find out the allocation block size of a volume with OS 10.6?
@timelessbeing — Info on the DEFAULT block allocation size for HFS+ volumes has been published by Apple.
See http://support.apple.com/kb/TA37344?viewlocale=en_US
It is my understanding that it has NOT varied between different versions of OS X. (i.e. It is the same in Tiger, Leopard and Snow Leopard).
For all HFS+ volumes greater than 1 GB, it is 4 KB.
Anyone know how to use bad block numbers, to find the associated file(s) affected?
In the old days of unix, I seem to recall using a command I cannot remember the name of, but it was something like icheck, to go from bad area on disk to inode number, then using ncheck command to find the file associated with it.
If a disk was critical and couldn’t be replaced, and had just a few errors, we used to rename the file to .bad and then try to copy from another machine. Calling the file .bad would mean that it only got “hit” during fsck, nobody ever read or deleted them.
Anyway, is there a way to go from a bad sector to find what is actually corrupt, filename?