Date: Fri, 27 Jun 2008 07:43:58 -0400 From: Michael Powell <nightrecon@verizon.net> To: freebsd-questions@freebsd.org Subject: Re: to scsi or not to scsi Message-ID: <g42jmq$8ec$1@ger.gmane.org> References: <20080626092558.1a17d7d2@gom.home> <4863E58C.2060602@webrz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Jos Chrispijn wrote: >> prad wrote: >> i've heard scsi hard drives are really good. >> i've also seen at least one site which claims that ide easily >> outperform scsi. >> [snip] > Prad, > > Have a look at this URL: http://www.pugetsystems.com/articles.php?id=19 > While I found this interesting, I also felt some data points could have been added. I believe these have some bearing for decision making as they better define the choice based upon what task, or purpose, the system is being called upon to perform. The concept that SATA subsystems will tend to consume more CPU cycles because SCSI controllers have onboard processors is somewhat nullified when considering controllers such as the Areca 1210 and the 3Ware type of products. One historical difference wrt to desktop type machines that manufacturers stuck RAID controllers on in order to have marketing buzzwords is that they were essentially useless for performance purposes. They were all hung off the Southbridge and were hamstrung by the maximum bus throughput between the South and North Bridge. The PCI-X bus was designed for server boards so this kind of bottleneck would not hamper performance. With the advent of PCI-E 8x slots and controllers this same situation has come to the SATA arena. The next consideration will be purpose: is the box going to be used as an inexpensive disk-to-disk NAS, file serving, or some other generic mode where size and high sequential throughput are primary concerns. Or is it called upon to perform lots of quick random selections of data such as a multithreaded database server? One item that gets lost in the RAID discussion is that, while sequential r/w performance generally goes up as you add more drives to the array, latency also increases. The additional latencies introduced may not matter as much to the sequential throughput scenario but will have more impact on the database server one. So the with sequential file serving it is OK to use 8-9ms seek time drives as we are more interested in sequential throughput and not as concerned with latency. Here SATA is probably a good match. For the high performance database server application you are going to want to use 3-4ms seek time drives to keep latencies under control while adding drives to the array. These are going to be the more expensive high RPM SAS and Fibre Channel drives. If you're already spending $40K/CPU for Oracle what's a few more dollars for Fibre Channel? :-) Can't wait for SSD devices to replace this. Just my $.02 here - I thought I'd toss this out in case anyone might find it interesting. -Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?g42jmq$8ec$1>