Guidelines
The following guidelines apply to hard drives in general, but are of particular importance with RAID configurations.
Mac OS X caching
All disktester commands bypass the MacOS X file system cache (or rather, DiskTester sets the force-read and no-cache flags).
Thus, test timings and rates are always real throughput to the disk(s)/volume. However, large caches on some disks, especially striped RAID volumes can have very large caches necessitating relatively large test sizes for an accurate picture.
For example, with a RAID 0 stripe of 4 disks each with a 32MB cache means that 128MB of cache memory is present. As a rule of thumb, use a test size that is at least 8 times larger than the total size of the disk caches, with 16 or 32 times preferred for the most consistent results.
Turn off interfering programs — Spotlight and Time Machine
When testing your volumes/drives for speed, turn off Time Machine and exclude the test volume from backups. Don’t forget to turn Time Machine back on if you use it.
Spotlight is a particularly nasty offender. Be sure to exclude the test drive from Spotlight indexing. Failure to do so with some tests can hang the machine for hours as Spotlight attempts to index a multi-terabyte file.
Running other programs while testing
Test results can be affected by other programs if they access the disk being tested (or in some cases even if non-test disks are accessed). Other programs also consume memory—which might mean that MacOS could be forced to use virtual memory, which can cause disk access and erratic results while testing.
For these reasons, you should run performance-oriented tests only after quitting other applications, and making sure “background” programs like Apple’s SpotLight are not indexing any drive(s) during the test.
Don’t assume that all similarly specified hard drives will perform equivalently
Don’t even assume the exact same model drive will perform the same. Sometimes there can be “duds” which are up to 10% slower than other samples. Sometimes these duds are duds because of a large number of bad blocks which have to be mapped out— it’s a warning sign: use fill-volume with a new drive.
Take 3 drives from 3 vendors, all of which are 7200rpm with a 16MB-buffer. Test them singly and in a striped RAID configuration and you’ll often find that there are distinct performance differences. General benchmarks from generic testing sites are often of little help for determining actual performance with your particular hardware and software. Test and observe, don’t assume.
Factors that can influence performance include:
- the drive itself, including its firmware version, and the specific model used;
- amount of free space on the volume;
- the area of the volume being tested;
- random vs sequential access;
- size of the data transfer your application(s) typically use;
- the type of interface (SATA/eSATA, Firewire, USB);
- whether Port Multiplication or direct connect is used (SATA);
- the machine and the type of slot used (eg PCI vs PCI-X vs PCI-Express)
- the host adapter used;
- cable length and/or electrical interference, low-quality power, etc;
- other programs, including invisible background programs such as SpotLight or Time Machine;
- anti-virus software.
This is not an exhaustive list, but it should serve to illustrate that getting top performance from any particular setup is not something you can be assured of from a generic review of a hard disk.
Don’t assume a device is reliable until you’ve tested it.
Multiple factors can induce flaky performance in a disk subsystem. These include:
- firmware bugs in the host adapter or drive(s);
- excessive bad blocks;
- mismatched hard drives in a RAID array;
- unshielded or damaged cables;
- poor-quality power supply.
Use DiskTester’s test-reliability command to verify that your volumes are reliable (including network volumes). But always test a new volume with fill-volume first.
Do not assume your disk/volume is reliable before using it for “production”. Always have a recent backup, preferably no fewer than three backups stored away from the computer.
The most troublesome type of failures are intermittent failures, which are difficult to detect except with the help of programs like IntegrityChecker. Though rare, intermittent failures are particularly insidious, because they can alter data without being detected. Bad data then gets backed up, replicating the damage. Long-term storage suggest archiving (read-only backup) is appropriate for some users.
Read only
DiskTester never opens your files in anything but “read only” mode; it never writes to your files. Of course, some commands like fill-volume create new files for testing, but those are test files.
DiskTester cannot change, modify or corrupt your files, but a flaky system can crash, which can lead to problems. One worthwhile role of DiskTester to flush out any problems before trusting a machine for your work.
Copyright © 2008-2010 diglloyd Inc, all rights reserved