When a hard drive is shipped from the factory, the recording media is a blank slate with possible bad areas. It’s always a good idea to verify your new hard drive before putting it into “production use”.
Most bad areas can be mapped out, but this can result in oddball performance anomalies. While not a big deal for a single drive, it’s a glitch for a multi-drive RAID setup.
Verifying drives is especially good idea for RAID-0 striping, where one goofy drive can slow down the whole RAID. Variations up to 10% in speed can be observed between identical model drives, with the “dogs” perhaps being future drives more likely to fail: buy 5 and use the fastest 4 for a 4-drive RAID. Test each drive individually for starters, then test as a RAID later.
Not long ago, I cherry picked 4 Hitachi 7K2000 drives for my main Mac Pro. I saw speeds from 118MB/sec to 133MB/sec. This four fastest drives yielded about 520MB/sec speed versus 480MB/sec for an average setup. Not a huge amount, but why not? The other drives became backups, and the one serious dud was returned.
How DiskTester helps
DiskTester makes the testing and verification process easy with its fill-volume facility. By doing so, the drive is forced to detect and map out any bad blocks. In addition, DiskTester verifies all data during the read phase of fill-volume (which can be repeated so long as the created files remains on the disk).
The detailed results across the entire drive can be graphed to show any performance anomalies, stutter, etc. This is true for single drives and RAID.
Video users in particular might want to verify that the drive or the RAID doesn’t have downward spikes in performance, so as to preclude lost frames.
Graphing the results
When DiskTester has finished filling the volume, you can paste the numbers into the supplied spreadsheet. This is a fantastic way to see just what your drive is doing
In the graph below, the decline in speed across the drive is readily visible, see Why You Need More Space Than You Need. . The spike for the last 1% of the drive should be ignored; this is not a drive issue but rather a Mac OS X file system behavior when the drive is almost full.