- Weedy SCSI performance
How so?
We're living in the age of Wide Ultra SCSI. Maybe a NetApp engineer can comment on whether this would, or would not, make much of a real world performance. I was under the impression that you'd get more TPS...
Faster disks only improve performance if disks are the bottleneck. Otherwise, they had expense and potentially reduce reliability (due to greater heat as well as being closer to the bleeding edge). We design our filers so everything runs out at about the same time. That means you're not paying for hardware which gives you no benefit. Alternately, it means upgrading just one component probably won't accomplish much.
One case I'm familiar with is the F330. Customers asked why we were selling them with Hawks when other vendors were shipping Barracudas. We tried some Barracudas in one. As expected, the performance change was a good approximation of zero, so putting in Barracudas would be pointless. Customers also asked why we only put in a 90 MHz Pentium. We tried a clock-doubled one and it, too, had virtually no effect. It turns out that for most uses, the PCI bus seems to be the bottleneck in the F330. This is mostly due to the Neptune (?) chipset used on the motherboard -- it was decent for our goals at the time, but newer designs do much better.
- Lack of other RAID implementations
Uhm, what else do you want to do?
Straight mirrors....straight concatenating and striping...
You can in fact do both on a filer, albeit with a few restrictions, and neither is something we support.
For straight mirroring, just use one data drive per RAID-4 group. The parity drive is in effect a mirror, and our xor code is clever enough to recognize this degenerate case. That does of course put a severe limit on how big your file system can be, though as someone else noted, careful examination of our SFS 2 results may be enlightening in this regard.
Straight concatenation and striping is a bit hokier. For this, build up your system and then yank the parity drive. The system will run in degraded mode, but since it's the parity drive that's missing, it will simply note when writing that it doesn't need to bother doing all the xor calculations. Thus, it should be somewhat faster for writes, and no worse for reads. *I* wouldn't want to run that way, but you can if you like.
(At one point, we considered running a benchmark on a machine with just a parity disk -- you know, we can beat vendor X even with one hand tied behind our back. Never got around to doing it, though.)
-- Karl Swartz - Technical Marketing Engineer Network Appliance kls@netapp.com (W) kls@chicago.com (H)