UP -- Return to the contents page
NEXT -- Go to the next section.
BACK -- Go to the previous section.
An industry insider (a man who buys hard drives for systems integration) has passed us some interesting tips about drive brands. He says the absolute best-quality drives are the Hewlett-Packards but you will pay a hefty premium for that quality.
The other top-tier manufacturers are Quantum and Seagate; these drives combine cutting-edge technology with very aggressive pricing.
The second tier consists of Maxtor, Conner, and Western Digital.
Maxtor often leads in capacity and speed, but at some cost in other quality measures. For example, many of the high-capacity Maxtor drives have serious RFI emission problems which can cause high error rates. SCSI has built-in ECC correction, so SCSI drives only take a performance hit from this; but it can lead to actual errors from IDE drives.
Western Digital sells most of its output to Gateway at sweetheart prices; WD drives are thus not widely available elsewhere.
The third tier consists of Fujitsu, Toshiba, and everyone else. My friend observes that the Japanese, despite their reputation for process engineering savvy, are notably poor at drive manufacturing; they've never spent the money and engineering time needed to get really good at making the media.
If you see JTS drives on offer, run away. It is reliably reported that they are horrible.
Just as a matter of interest, he also says that hard drives typically start their life cycle at an OEM price around $400 each. When the price erodes to around $180, the product gets turfed --- there's no margin any more.
I've found a good cheap source for reconditioned SCSI disks at Uptime Computer Support Services.
Previous issues said "Disk cacheing is good, but there can be too much of a good thing. Excessively large caches will slow the system because the overhead for cache fills swamps the real accesses (this is especially a trap for databases and other applications that do non-sequential I/O). More than 100K of cache is probably a bad idea for a general-purpose Unix box; watch out for manufacturers who inflate cache size because memory is cheap and they think customers will be impressed by big numbers." This may no longer be true on current hardware; in particular, most controllers will interrupt a cache-fill to fulfill a `real' read request.
In any case, having a large cached hard drive (particularly in the IDEs) often does not translate to better performance. For example, Quantum makes a 210Mb IDE drive which comes with 256Kb cache. Conner and Maxtor also have 210Mb drives, but only with 64Kb caches. The transfer rate on the drives, however, show that the Quantum comes in at 890Kb/sec, while the Maxtor and Conner fly away at 1200Kb/sec. Clearly, the Conner and Maxtor make much better use of their smaller caches.
However, it may be that any hardware disk cacheing is a lose for Unix! Scott Bennett reports a discussion on comp.unix.wizards: "nobody found the hardware disk caches to be as effective in terms of performance as the file system buffer cache...In many cases, disabling the hardware cache improved system performance substantially. The interpretation of these results was that the cacheing algorithm in the kernel was superior to, or at least better tuned to Unix accesses than, the hardware cacheing algorithms."
On the other hand, Stuart Lynne <[email protected]> writes:
Ok. What I did was to use the iozone program.
What this showed was that on my root disk in single user mode I could get about 500kb for writing and 1000kb for reading a 10MB file. With the disk cache disabled I was able to get the same for writing but only about 500kb for reading. I.e. it appears the cache is a win for reading, at least if you have nothing else happening.
Next I used a script which started up iozone in parallel on all four disks, two to each of the big disks (three) and one on the smaller disk. A total of seven iozone's competing with each other.
This showed several interesting results. First it was apparant that higher numbered drives did get priority on the SCSI bus. They consistantly got better throughput when competing against lower numbered drives. Specifically drive 1 got better results than drive 0 on controller 0. Drive 4 got better results than drive 3 on controller 1. All of the drives are high end Seagate and have similiar characteristics.
In general with cache enabled the results where better for reading than writing. When the cache was disabled the write speed in some cases went up a bit and the read speed dropped. It would seem that the readahead in some cases can compete with the writes and slow them down.
My conclusions are that we'll see better performance with the cache. First the tendency is to do more reading than writing in your average Unix system so we probably want to optimize that. Second if we assume an adequate system cache slow writes shouldn't affect an individual process much. When we write we are filling the cache and we don't usually care how long it takes to get flushed. Of course we would notice it when writing very large files.
Thus (this is your humble editor again), I can only recommend experiment. Try disabling the cache. Your throughput may go up!