SAS Expanders and Cascading: Enclosure and Bandwidth Limits
A SAS host bus adapter with eight ports can address hundreds of drives. The component that makes that possible is the expander, and it is the reason a 24-bay server works at all with a controller that has nowhere near 24 connections. It is also the reason a well-specified array can turn out slower than expected once it is full.
This guide explains what an expander does, how cascading works and where it stops, why bandwidth is shared rather than multiplied, and the SATA behaviour that catches people out when mixing drive types behind one.
What an expander is
A SAS expander is a switch. It sits between the controller and the drives and routes traffic, letting a small number of controller ports reach a much larger number of devices.
Most server backplanes with more than eight or twelve bays have one built in, and most external JBOD enclosures have one or two. You rarely buy an expander as a separate item; you inherit it as part of the chassis. Our guides on server backplanes, caddies and bay blanks and JBOD enclosures cover where they live.
Without an expander, the count is direct. An eight-port HBA reaches eight drives, usually via two SFF-8643 or SFF-8087 connectors of four lanes each. With an expander, those same eight lanes feed a backplane serving 24 bays or more.
Bandwidth is divided, not multiplied
This is the part that gets missed, and it is the source of most expander-related disappointment.
The link between the controller and the expander is the bottleneck for everything behind it. Four 12Gb/s lanes in one cable give roughly 4.8 GB/s of theoretical aggregate. Put 24 drives behind that and they share it.
For hard drives this is usually fine. Twenty-four 7,200 RPM nearline drives streaming at once might total 5 GB/s in a perfect sequential test, and real workloads rarely approach that. The expander is not your constraint.
For SSDs it frequently is not fine. A shelf of SAS SSDs can saturate a four-lane uplink with a handful of drives, and the rest add capacity without adding throughput. If you are building a flash tier behind an expander, work out the aggregate the drives can produce and compare it against the uplink before assuming the design scales.
Wide ports help, if the chassis supports them. Many backplanes accept two uplink cables rather than one, doubling the path. It is often an option nobody enabled because the second cable was not fitted. Worth checking on an existing system that feels slower than it should. Our guide on server storage cables and connectors covers the connector families.
Cascading, and where it stops
Expanders can connect to other expanders, which is how a single controller drives multiple external enclosures daisy-chained together.
The SAS addressing scheme allows for a very large number of devices, far more than any practical deployment reaches. The real limits arrive well before that:
Bandwidth compounds downward. Every enclosure in the chain shares the same uplink back to the controller. The fourth shelf is not getting its own path; it is sharing the first shelf's. For capacity and archive work that is acceptable. For anything performance-sensitive it is not.
Vendor support limits are lower than the standard. Controller and enclosure vendors publish a maximum number of enclosures per chain and per controller, and those figures are what support will hold you to. Exceeding them may work and will not be supported.
Discovery time grows. Long chains take noticeably longer to enumerate at boot, and a topology change causes a rediscovery that ripples through.
Fault domains widen. A failed expander or cable partway along a chain takes out everything downstream of it, not just that enclosure. Dual-path cabling addresses this, and it is what dual-ported SAS drives exist for. Our guide on dual-port SAS drives and multipath covers the redundancy side.
SATA drives behind expanders
SAS expanders can carry SATA drives using a translation layer, and this works — but SATA and SAS do not behave the same way behind one.
SATA drives are single-ported. They cannot use dual-path redundancy, so in a dual-domain enclosure they are reachable through one path only. If that path fails, the drive is gone even though its SAS neighbours stay online.
SATA has no native command queuing across the expander in the way SAS does, and its error recovery behaviour differs, which is why large SATA populations behind expanders have a reputation for occasional resets and timeouts that pure SAS populations do not.
Mixing SAS and SATA in one enclosure is common and usually fine, but it is worth knowing that the SATA drives are the ones that will misbehave first under stress. If the enclosure is doing anything important, SAS or NL-SAS is the safer specification. Our guide on SAS versus SATA versus NVMe covers the differences, and NL-SAS versus SATA covers the nearline choice specifically.
Diagnosing expander problems
Expander faults present strangely, because the symptom is usually not at the expander.
A whole group of bays disappearing at once is almost never a drive problem. It points at a cable, an expander, or a backplane power fault. Our guide on a server hard drive not being detected works through this in order.
Intermittent drive drops across unrelated bays often trace back to expander firmware or a marginal cable rather than to the drives being dropped.
One bad drive slowing the whole shelf is a real effect. A drive that is retrying holds up the expander's attention, and the impact shows up as general sluggishness rather than a pointed error. Reading drive health across the whole enclosure, not just the one that complained, is the way to find it. See reading drive health data.
Expander firmware is a real thing that needs managing. It is separate from controller firmware and from drive firmware, it is easy to forget, and vendor compatibility matrices specify combinations rather than individual versions. See hardware compatibility lists.
Specifying sensibly
For capacity-led nearline storage, expanders and cascading are exactly the right tool and the shared bandwidth rarely matters.
For a performance tier, count the aggregate throughput your drives can produce, compare it against the uplink you actually have cabled, and either widen the path or attach the drives more directly. For flash at scale, this is one of the reasons NVMe topologies displaced SAS expanders rather than extending them.
And whichever you build, cable it so a single failure does not take out a shelf. Our guide on DAS, NAS and SAN architecture covers where each topology belongs.
Sourcing
We supply enterprise SAS and SATA drives, HBAs, RAID controllers, cables and carriers for server and JBOD deployments. If you are populating an enclosure and want to know whether the uplink will carry what you are planning, send us the chassis model and the drives you have in mind and we will work through it before you order. Request a bulk quote or email sarah.jane@techsellerusa.com.
Common questions
What does a SAS expander do?
It acts as a switch between the controller and the drives, letting a small number of controller ports reach a much larger number of devices. An eight-port HBA without an expander reaches eight drives; with one, those same lanes can feed a 24-bay backplane or an external enclosure. Most backplanes above eight or twelve bays have an expander built in, so you usually inherit it with the chassis rather than buying it.
Do expanders slow storage down?
They divide bandwidth rather than multiplying it. Everything behind the expander shares the uplink to the controller, so four 12Gb/s lanes give roughly 4.8 GB/s aggregate for however many drives sit behind them. For hard drives this is rarely the constraint. For SAS SSDs it often is, because a handful of flash drives can saturate a four-lane uplink and the rest add capacity without throughput.
How many enclosures can I cascade?
The SAS addressing scheme allows far more than any practical deployment reaches, so the real limits are your vendor's supported maximum per chain and per controller, and bandwidth. Every enclosure in a chain shares the same uplink back to the controller, so the fourth shelf is sharing the first shelf's path. Check the vendor figure, because exceeding it may work and will not be supported.
Can I use SATA drives behind a SAS expander?
Yes, through a translation layer, and it works. But SATA drives are single-ported, so they cannot use dual-path redundancy and are reachable through one path only even in a dual-domain enclosure. Their error recovery behaviour also differs, which is why large SATA populations behind expanders have a reputation for occasional resets and timeouts. For anything important, SAS or NL-SAS is the safer specification.
A whole group of bays disappeared at once. Is that drive failure?
Almost certainly not. Drives fail individually; several bays vanishing together points at a cable, an expander, or a backplane power fault. In a cascaded setup, a failed expander or cable partway along the chain takes out everything downstream of it as well, which can look like a catastrophic multi-drive failure when it is a single connection. Check the topology before assuming the drives are gone.
Can one bad drive slow down the whole enclosure?
Yes, and it is an under-appreciated failure mode. A drive that is retrying repeatedly holds the expander's attention, and the effect shows as general sluggishness across the shelf rather than a clear error pointing at the culprit. When an enclosure feels slow with nothing obviously wrong, read health data across every drive in it rather than only the one that raised a warning.
If you are populating an enclosure and want to know whether the uplink will carry the plan, send us the chassis model and the drives you have in mind.
