> But seriously, the big issue with SCSI, is that the SCSI commands are sent > over the SCSI bus at the original (legacy) rate of 5 Mbits/Sec in 8-bit > mode.
Actually, this isn't true on the newest (Ultra320) SCSI systems, though I don't know if the 3320 supports packetized SCSI. It's definitely an issue for older SCSI buses if the reads and writes are small, less than a megabyte, say. (For data warehousing applications you should see larger reads, as long as your data is laid out contiguously on disk.) There's rather a nice chart at http://www.hitachigst.com/hdd/library/whitepap/tech/hdwpacket.htm showing how the overhead grows with the speed of the bus. > And since it takes an average of 5 SCSI commands to do something useful Urm? What's wrong with just READ(10) or WRITE(10)? > Also, it takes a lot of time to send those commands - so you have latency. Not much compared to the rotational latency if you're actually reading from media, though. (Measured latency for a read operation with disconnect/reconnect on a parallel SCSI bus is around 22 µs. [That's microseconds in case your mail program/browser doesn't get it right.]) > This is the main reason why SCSI is EOL I presume you mean parallel SCSI? I'd argue that the larger reason was the cost and cooling requirements of parallel cabling; SAS seems to be alive, at least, if not taking off quickly. FC, SAS, and SATA all have lower overhead since they're point-to-point and don't need to arbitrate (or drive multiple receivers). How noticeable this is depends on your application. For large sequential I/O, the data transfer time dominates the overhead; for random I/O, the seek time and rotational latency dominates the overhead. Only in the cases where you're doing fairly small sequential I/Os, you have a very fast caching controller, or you have so many spindles on one connection that you have enough I/O operations in flight to keep the bus busy, will this matter much. For this application, with a mix of random & sequential I/O, FC disks, or other disks with very low seek+rotation times, might perform quite a lot better than inexpensive disks with longer seek+rotation times. I'd be concerned that the updates would dominate performance, unless they're happening at a rate of fewer than about 50/second/spindle. Anton This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
