Server Hardware Explained (Part 7)

by [Published on 27 March 2012 / Last Updated on 27 March 2012]

This article continues the discussion of server hardware by comparing SAS to legacy SCSI.

If you would like to read the other parts in this article series please go to:


Now that I have talked about solid state storage, I want to turn my attention to Serial Attached SCSI (SAS). Although solid state storage is almost certain to become the dominant storage medium in a few years, SAS is generally the preferred storage medium for servers today. SAS drives perform well, are relatively inexpensive, have high capacities, and are almost universally accepted.

In order to really appreciate SAS drives, you need a little bit of historical prospective. Back in the 1990’s almost all servers used SCSI (pronounced skuzzy) storage. As someone who worked as a systems engineer during that time period, I can tell you from firsthand experience that working with SCSI tended to be a real pain.

The legacy SCSI implementation that was used in the ‘90s was based on something called the multidrop bus (which was commonly referred to as the SCSI bus). The SCSI bus consisted of a controller card (which included the SCSI initiator), a ribbon cable, one or more SCSI devices, and a terminator.

The nice thing about this original SCSI implementation was that it allowed you to mix match devices, so long as each device was assigned a unique SCSI ID number (more on this later) and conformed to the same flavor of SCSI. As such, you could mix hard drives, tape drives, or even scanners on a single SCSI bus.

Unfortunately, this flexibility came at a price. For starters, each SCSI bus could support a maximum of either eight or sixteen devices. Because SCSI used a parallel bus all of the devices on the bus shared the bus’s bandwidth. As such, the number of devices that were in use on the bus at any one time affected the individual device’s performance.

The 1990’s SCSI implementation could also be difficult to work with because of hardware limitations. Each device on a SCSI bus had to be assigned a unique SCSI ID number. The SCSI ID number gave the controller a way of identifying the device. Typically a device’s SCSI ID number was set through either the use of switches, jumpers, or a dial on the back of the device.

The thing that made SCSI IDs so tricky to work with was that not every device supported every SCSI ID. For instance if you had used every available number except for 3 and the device that you wanted to add didn’t support the number 3 then you would have to reconfigure the SCSI IDs for the existing devices in a way that would give every device a unique SCSI ID.

As if that were not bad enough, the simple fact that SCSI IDs were often set through the use of switches or dials meant that if an external device got bumped then its SCSI ID could end up getting changed. I lost count of the number of times that I had to troubleshoot problems related to SCSI IDs that were accidentally changed.

Another problem that often plagued legacy SCSI implementations was the requirement for termination. Devices sharing a SCSI bus were daisy chained together, and the last device in the chain required a terminator. Most of the SCSI devices that I worked with required a hardware terminator, but some of the more advanced devices could be self-terminated. At any rate, terminators would sometimes either come loose or they would just go bad for no apparent reason. When this happened, it would lead to all sorts of problems for the devices on the SCSI bus.

I could go on and on about the complexities of things like locating compatible drivers and ensuring compatibility between SCSI devices and controller cards, but I think that by now you probably get the picture that it could be challenging to make legacy SCSI implementations work correctly.

A New Generation of SCSI

After reading about the challenges of working with legacy SCSI, you might be hesitant to even consider using Serial Attached SCSI (SAS). However, I am happy to say that SCSI has finally “grown up” and there is no reason to avoid using SAS.

In case you are wondering, SAS does not have much in common with legacy SCSI. SAS still supports the SCSI command set, and some of the terminology used for SAS hardware still matches that of legacy SCSI hardware, but the similarities pretty much end there.

Even the words Serial Attached SCSI convey the idea that SAS is different from legacy SCSI. As you will recall, legacy SCSI was based on a parallel bus that supported either eight or sixteen devices. In contrast, SAS uses a serial bus and supports up to a staggering 65,535 devices (if port expanders are used).

The fact that SAS makes use of a serial bus means that SAS not only supports more devices than legacy SCSI, but also achieves much higher throughput. One of the big limitations of the parallel SCSI bus was that all of the devices on the bus shared the bus’s bandwidth. In a SAS implementation, each device has a dedicated connection to the SCSI Initiator (usually the controller card). As such, SAS devices are not impacted by the bandwidth that is consumed by other devices. In fact, SAS devices typically support a transfer speed of either 3 Gbps or 6 Gbps.

Another advantage to the serial bus is that because only a single device is connected to each SAS port, there is no need for termination.

So what about the challenges of working with SCSI IDs? Well, SAS still uses them (although they are now called SCSI port identifiers). The good news is that the ID numbers are no longer something that you need to worry about because the SCSI manufacturers have followed in the steps of the network card manufacturers.

When I first got started with networking in the early 1990s, each network card had to be manually assigned a Media Access Control (MAC) address through the use of DIP switches. Every card on the entire network had to be assigned a different MAC address. Eventually the network card manufacturers came up with a method for assigning globally unique MAC addresses at the factory so for all practical purposes manually assigning MAC addresses is a thing of the past.

The same basic thing has happened with SCSI IDs. Each SAS port is assigned a globally unique SCSI port identifier. Administrators no longer need to worry about assigning SCSI IDs.

SCSI Terminology

I want to wrap things up by explaining a few terms related to SAS and SCSI that you are likely to encounter.

Initiator – The initiator is the component that facilitates communications with SCSI devices. In the case of SAS, the initiator is usually either built into the server’s motherboard or into an add-on SAS controller card.

Target – A target is a generic term for a device that the initiator communicates with. A target could refer to a single SAS drive or to an entire disk array.

Service Delivery Subsystem – In the case of SAS, the Service Delivery Subsystem usually refers to the cables that connect the initiator to the target.

Expander – Earlier I mentioned that SAS could support over 65,000 devices if expanders were used. An expander is simply a multiplexer that allows multiple SAS devices to be connected to a single port on the initiator.


Now that I have talked about SAS and legacy SCSI, I want to spend the next article talking about the mixing of SAS and SATA drives on a common bus.

If you would like to read the other parts in this article series please go to:

See Also

The Author — Brien M. Posey

Brien M. Posey avatar

Brien Posey is an MCSE and has won the Microsoft MVP award for the last few years. Brien has written well over 4,000 technical articles and written or contributed material to 27 books.


Featured Links