SATA, SAS, NVMe and M.2: what actually plugs into what

SATA is a bus, a protocol and a connector that happen to share one name, which is why it is the easy case and why it teaches the wrong lesson. SAS is a different protocol over an electrically similar bus, on a connector deliberately shaped so the mistake cannot be made in one direction and is invisible in the other. NVMe is neither a bus nor a connector: it is a command set, and it runs over PCIe inside a machine and over Ethernet between machines.

Three separate things travel under the word “interface”, and a listing usually names one of them: the bus (the electrical link and its signalling rate), the protocol (the command set spoken over it), and the connector. They vary independently, and nearly every expensive mistake in buying a drive comes from assuming they do not.

M.2 is a connector: it carries SATA or it carries PCIe, and two drives that fit the same slot can be incompatible with it. U.2 is a connector that looks like SAS and usually carries neither SAS nor SATA. U.3 uses the same connector again and reverses which direction of substitution is safe. Each of those is a real failure that costs a return, and each is visible in the specification before it is visible in the machine.

Rows two and three share a connector and nothing else. So do rows four and eight. The notch, the plug and the cable tell you what fits. Nothing about what fits tells you what works.

SATA has had three speeds in twenty-six years, and its successor was withdrawn

SATA-IO dates the whole history itself, for its twentieth anniversary, and it is short enough to print. Its anniversary page does not start with a specification: Serial ATA “was introduced to the world in February 2000” through the efforts of the five companies it names - APT Technologies, Dell, Intel, Maxtor and Seagate. That is the announcement of a working group. The dates that follow are from SATA-IO’s twenty-year infographic, the fuller of its two timelines. The earliest revision it dates is 1.0a, in January 2003, carrying 1.5 Gb/s. Revision 2.0 in April 2004 brought 3 Gb/s. SATA-IO was incorporated as the maintaining body in July 2004; revision 2.5 in October 2005 consolidated the specification into a single document, and revision 2.6 followed in February 2007. Revision 3.0 in August 2008 brought 6 Gb/s. Then revision 3.1 in July 2011, 3.2 in August 2013, 3.3 in February 2016, 3.4 in June 2018 and 3.5 in July 2020. The anniversary page’s own table leaves revision 2.5 out and dates 3.5 to June 2020; the infographic and SATA-IO’s press release for 3.5, dated 15 July 2020, both say July.

Three signalling rates in twenty-six years, and the last of them arrived eighteen years ago. Everything since revision 3.0 has been features.

The part usually told as a rumour has a documented answer. A faster successor was not merely discussed, it was standardised and then withdrawn. SATA Express appeared in revision 3.2 in August 2013, carrying up to 16 Gb/s over two PCIe 3.0 lanes - roughly 2 GB/s, more than three times SATA 6Gb/s. SATA-IO’s infographic then lists “Obsolete SATA Express” as one of three changes in revision 3.4 in June 2018, alongside writeable-log clarifications and Device Sleep timing requirements. The successor path existed in the standard for four years and ten months and was removed.

Revision 3.5, published 15 July 2020, added exactly three things and none of them is speed: Device Transmit Emphasis for the Gen 3 PHY, Defined Ordered NCQ Commands, and Command Duration Limit - the last aligning SATA with the Open Compute Project’s “Fast Fail” requirement, specified in the INCITS T13 standard. It is still the current revision.

There is no SATA-IO announcement cancelling a fourth generation, and this guide will not claim one. What SATA-IO does publish is its current technical overview, which still says “SATA supports 6.0 Gb/s, 3.0 Gb/s and 1.5 Gb/s data transfer speeds” and lists no roadmap beyond them. The absence is the evidence. A standards body that intended a faster generation would have a rate on that page.

The names the standards body has disowned

SATA-IO’s naming guidelines are blunt about the terms every listing on eBay uses: “Do not use the terms ‘SATA II’ or ‘SATA III’, which are incorrect and have no meaning.” The correct product names are SATA 6Gb/s, SATA 3Gb/s and SATA 1.5Gb/s. “SATA II” was the name of the standards organisation that preceded SATA-IO, not a speed grade. SATA-IO also asks that “Gen3” and “Third Generation” stay out of product naming, even though the specification itself uses Gen1, Gen2 and Gen3 internally as technical names for the three PHY rates.

This guide will use the wrong terms anyway, deliberately, because they are what sellers write and what buyers search for. But know that a listing saying “SATA III” is quoting a name that does not exist in any specification, and that a seller who writes “SATA 3.0” may mean the 6 Gb/s PHY, revision 3.0 of the standard, or nothing at all. The number in a listing title carries no reliable information. The number returned by the drive does.

8b/10b costs a flat fifth of the wire

The link uses 8b/10b encoding - eight bits of payload transmitted as ten bits on the wire, so the receiver can recover a clock from the data and the line stays DC-balanced. That 20 per cent is not overhead you can tune away; it is how the bits arrive at all. All three SATA rates use it, which is why the payload figures are round.

SATA 6Gb/s signalling rate                   6,000,000,000 bit/s
8b/10b: 8 payload bits per 10 transmitted     x 8 / 10
                                           = 4,800,000,000 bit/s
/ 8 bits per byte                          =   600,000,000 byte/s
                                           =       600 MB/s   (572.20 MiB/s)

SATA 3Gb/s                                 =       300 MB/s   (286.10 MiB/s)
SATA 1.5Gb/s                               =       150 MB/s   (143.05 MiB/s)

Those 600, 300 and 150 figures are not a derivation this site invented. They are what drive vendors print. Western Digital’s Ultrastar DC HC580 datasheet lists “Interface transfer rate (MB/s, max)” as 600 for the SATA model and 1200 for the SAS model, directly above the sustained transfer rate - the payload number, not the signalling rate.

Below that sits framing: Frame Information Structures, primitives, flow control and the gaps between them. That cost is real, variable and not published as a single figure. Sequential benchmarks on SATA SSDs cluster near 550 MB/s, which implies roughly 8 per cent of framing overhead, but 550 is an observed number from the market rather than a specification value, and it is mine to defend rather than a vendor’s to stand behind.

This is why every SATA SSD ever made benchmarks at roughly the same number. A 2013 drive and a 2026 drive both report about 550 MB/s sequential read, not because the flash is equally fast but because the bus saturated more than a decade ago. Comparing sequential figures between two SATA SSDs tells you nothing; their random I/O, their sustained write once the SLC cache is spent, and their endurance rating still differ enormously.

What the link trained at is not what the drive supports

Check the negotiated rate, not the capability:

$ sudo smartctl -i /dev/sda | grep -i 'SATA Version'
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)

(current: 3.0 Gb/s) on a 6.0-capable drive means the link fell back - a marginal cable, a dirty connector, an older controller, or a backplane that is itself only 3 Gb/s. This matters more now than it used to, because a 3 Gb/s link is no longer generous. Three hundred megabytes per second of payload, minus framing, lands somewhere near 275 MB/s usable - an estimate of mine, derived the same way as the 550 figure above - and that is below the outer-track sustained rate of a current large hard drive. Twenty years ago the bus was comfortably ahead of the mechanism. On a 3 Gb/s port it is now behind it.

One hard drive uses under half the SATA link, and the biggest is not the fastest

For a hard drive the SATA ceiling is close to irrelevant, and now there is a vendor figure to put against it rather than a guess.

Western Digital’s Ultrastar DC HC580 datasheet describes a 24 TB, 7200 RPM, conventionally recorded drive with ten disks and a 512 MB buffer. Its maximum sustained transfer rate is 298 MB/s, which the datasheet also prints as 284 MiB/s; the 22 TB model of the same family gives 291 MB/s / 277 MiB/s.

sustained transfer rate, HC580 24TB           298 MB/s
SATA 6Gb/s payload ceiling                    600 MB/s
fraction of the link consumed   298 / 600  =  49.7%

SAS 12Gb/s payload ceiling                  1,200 MB/s
fraction of the link consumed   298 / 1200 =  24.8%

Two qualifications that the datasheet supplies and most quotations of it drop.

First, the maximum sustained rate is not the rate at LBA 0. WD’s own footnote says “the location of the max rate is at approximately 10 per cent into the capacity of the HDD”. Zoned bit recording puts more sectors on the longer outer tracks, so throughput falls as the head works inward; the published figure is a near-peak, and the inner tracks of the same drive run at roughly half of it.

Second, the largest drive is not the fastest. WD’s Ultrastar DC HC690, a shingled family reaching 32 TB, quotes 269 MB/s / 257 MiB/s for both 32 TB models and 260 MB/s / 248 MiB/s for both 30 TB models.

HC580 24 TB, conventional                        298 MB/s
HC690 32 TB, shingled                            269 MB/s
HC690 30 TB, shingled                            260 MB/s

32 TB against 24 TB   (298 - 269) / 298   =   9.7% slower
30 TB against 24 TB   (298 - 260) / 298   =  12.8% slower

Those percentages are arithmetic of mine on two WD datasheets; the datasheets give the transfer rates, not the comparison. The highest-capacity drive in the catalogue is about 10 per cent slower sequentially than the 24 TB conventional one, and the 30 TB model of the same family is nearly 13 per cent slower, because shingling buys areal density and not data rate. What shingling costs elsewhere is the subject of CMR versus SMR, and it is a far larger number than the 10 to 13 per cent it costs sequentially.

Random access does not touch the bus at all

The HC580 datasheet gives the random figure too, and it is the one that ends the argument: 212 IOPS at 4 KB random read, queue depth 32.

212 IOPS x 4,096 bytes                     =   868,352 byte/s
                                           =      0.87 MB/s
as a fraction of SATA 6Gb/s   0.87 / 600   =     0.145%
as a fraction of SAS 12Gb/s   0.87 / 1200  =     0.072%

A modern 7200 RPM enterprise drive doing random reads uses about one part in seven hundred of a SATA link. No interface upgrade has ever made a hard drive faster at random I/O, and none ever will, because the limit is a head on an arm above a platter turning at 120 revolutions per second, and that gap against flash is the whole subject of HDD or SSD. The same datasheet quotes a non-recoverable read error rate of 1 in 10^15 bits, which is the figure that actually decides array design - see drives for a NAS.

The practical consequence for buying: on a hard drive, the interface generation is close to a non-issue and you should spend the decision on capacity, recording technology and hours. On an SSD it is the whole ceiling.

AHCI’s 32 command slots are a ceiling, not a promise

The number everyone quotes when comparing AHCI with NVMe is queue depth, and it is both the least interesting difference and the one most often stated wrong.

The Advanced Host Controller Interface specification, revision 1.3.1, does not mandate 32 command slots. It permits between one and 32. The capability register field CAP.NCS is described as “a 0’s based value indicating the number of command slots per port supported by this HBA. A minimum of 1 and maximum of 32 slots per port can be supported.” The command list is itself optional: “an HBA which does not support a command list shall have a depth of one for this table.” An AHCI host bus adapter supports from 1 to 32 ports, and each port has its own list.

So “AHCI has 32 slots” should be read as “AHCI allows up to 32 slots per port, and the controller in front of you has published how many it actually has.”

There is a second constraint that matters more, and it is in the same document. In AHCI the NCQ tag is the command slot index. They are not independent numbers: “if a queued command is placed in slot 5, the tag for that command must be 5.” The effective queue depth is therefore the smaller of the two ends: “system software must determine the maximum tag allowed by the device and the HBA and it must use the lower bound of the two … if the HBA has 8 entries in its command list, and the SATA device only has 4, only tags 0 - 3 in the device may be used, and only command list entries 0 - 3 may be used in the HBA.” The specification’s worked example is an eight-slot HBA. The same rule run on a 32-slot controller in front of a drive that advertises four gives four.

Linux encodes the ceiling in headers rather than discovering it: include/linux/ata.h and include/linux/libata.h define ATA_MAX_QUEUE as 32 and ATA_DEF_QUEUE as 1, and set ATA_TAG_INTERNAL equal to ATA_MAX_QUEUE. Tags 0 to 31 go to queued I/O; a thirty-third slot is reserved for the driver’s own internal commands, which is why the per-port array is declared as qcmd[ATA_MAX_QUEUE + 1]. There is no kernel tunable that raises 32, because the NCQ tag in the standard is a five-bit field in the Sector Count register, and five bits is thirty-two values.

NCQ is a mechanical optimisation, and the mechanism is rotational

Native Command Queuing is usually described as “the drive reorders commands”, which is true and explains nothing. SATA-IO’s own illustration is the mechanism: an NCQ drive executes four commands in one and a quarter rotations where a non-NCQ drive needs two and three quarter rotations for the same four commands. The drive knows where the heads are and where the platter is in its rotation; the host does not. Given four outstanding requests it services them in the order that minimises the sum of seek and rotational latency, rather than in the order they arrived.

rotational period at 7200 RPM     60 / 7200          = 8.33 ms
four commands, no NCQ             2.75 rotations     = 22.9 ms
four commands, NCQ                1.25 rotations     = 10.4 ms
ratio                                                = 2.2x

That arithmetic is mine, applying SATA-IO’s rotation counts to a 7200 RPM spindle; SATA-IO gives the rotations, not the milliseconds. The point stands either way: NCQ’s benefit is overwhelmingly a rotating-media benefit. SATA-IO notes that NCQ also “allows solid state drives to access the stored command queue to boost performance”, which is a genuine but far smaller effect - an SSD has no rotational latency to optimise against, only internal parallelism to keep fed.

And on a desktop, queue depth rarely leaves single digits. The queue-depth comparison between AHCI and NVMe describes a difference that most consumer workloads never reach. What actually separates the two is the shape of the command path, and that is dealt with further down.

Pin 3 of the power connector, and why a working drive arrives dead

This is the single most common reason a used enterprise or shucked SATA drive appears to be broken on arrival, and it is not a fault.

The 15-pin SATA power connector has three pins - P1, P2 and P3 - that were originally the 3.3 V supply, and on older host connectors they were required to be bused together. SATA revision 3.2, in August 2013, reassigned P3 as DevSlp (Device Sleep). SATA revision 3.3, published 2 February 2016, then gave the same pin a second job: Power Disable, abbreviated PWDIS.

SATA-IO’s own technical proposal for the feature, TPR056, states the position precisely: “currently the SATA pin P3 is defined as the DEVSLP signal … this proposal defines an alternate use of pin P3 for the Power Disable control signal (PWDIS). Since Power Disable and Device Sleep are asserted by the same voltage level on P3, these two features are mutually exclusive.” One pin, three successive meanings, and the last two cannot coexist on the same drive.

The feature did not originate in SATA. The same proposal records that Seagate introduced Power Disable in T10 - the SAS and SCSI committee - and that SATA-IO adopted it because “many SATA storage devices, especially high capacity ones deployed in storage systems, are installed in SAS backplanes”. A data centre wants to power-cycle one bay without touching its neighbours, and a drive that has locked up needs a hardware power cut, not a bus reset.

On a desktop power supply that still delivers 3.3 V on P3, the drive is held in reset: no spin-up, no detection, no error message, no SMART. Western Digital’s tech brief on the feature describes both the failure and why software cannot rescue it: “some legacy power supplies provide 3.3V power on P3 (Pin 3), and this forces the HDD to get stuck in a hard reset condition”, and “this feature is hard wired. By sending a ‘high level’ signal to P3 (Pin 3), special circuitry on the HDD physically removes power to the SoC … This external circuitry cannot be configured by firmware.”

SAS drives are not affected, and the reason is in the same brief: on SAS, P3 is a no-connect in legacy systems, whereas “some legacy SATA power supplies tied P1 (Pin 1), P2 (Pin 2) and P3 (Pin 3) together to 3.3V resulting in P3 (Pin 3) being permanently powered high.”

The electrical detail, and the footnote that makes tape work

SATA-IO’s proposal specifies the signal at the device connector, and the numbers explain why the failure is so absolute.

A 3.3 V rail sits squarely inside the asserted band. There is no intermediate state, no timeout, no retry. The drive is doing exactly what the standard tells it to.

The fix is also written into the standard, as a footnote to that table: “the device shall allow power to be applied to the device circuitry if P3 is not connected on the host connector.” That one sentence is why all three of the usual workarounds are legitimate rather than hacks.

• A Molex-to-SATA power adapter. The four-pin Molex connector carries 12 V, 5 V and ground and has no 3.3 V line at all, so P3 arrives unconnected. WD’s brief recommends exactly this, noting it “removes power from P3 (Pin 3) and allows the drive to spin up normally”.
• Kapton tape over pins P1 to P3 of the drive’s power connector. Crude, reversible, and effective for the same reason. Cover all three, not just P3; they are adjacent and small, and the 3.3 V rail feeds nothing else the drive needs.
• A backplane that leaves P3 open, or drives it as intended.

A drive also tells you whether it implements the feature, if you can get it to power up at all. IDENTIFY DEVICE word 78 bit 12 reports “supports Power Disable feature”; word 79 bit 10 reports the feature enabled; word 77 bit 8 reports “Power Disable feature always enabled”. If the always-enabled bit is set, the feature cannot be turned off. Otherwise it is disabled by a power-on reset and is unaffected by hardware or software resets.

Before returning a used enterprise SATA drive as dead, try it on a Molex adapter. It costs a few pounds and it resolves a large fraction of “dead on arrival” reports.

One point this site cannot settle: Wikipedia’s SATA article states that revision 3.5 formally discontinued the 3.3 V supply. If true it would mean the rail is now dead by specification rather than merely unused, which would be a tidy end to the story. The SATA 3.5 specification is paywalled and SATA-IO’s press release for 3.5 does not mention it, so treat that as unconfirmed and keep the Molex adapter in the drawer regardless.

Reading Power Disable off a model number

Western Digital encodes the answer in Ultrastar model numbers, which means a listing photograph of the label can settle it before you bid. In a number of the form WUH722424ALxxyz:

So WUH722424ALE6L4 is a 512e SATA drive with the legacy pin 3 configuration and no encryption, and will spin up on any supply. WUH722424AL5201 is a 512e SAS drive with Power Disable and TCG-Enterprise self-encryption - and, being SAS, is unaffected by the desktop supply problem in any case. The scheme is WD’s, printed in its own datasheets; other vendors do not use it and generally do not encode the feature in the part number at all.

The encryption digit deserves a separate warning. A self-encrypting drive pulled from an array may arrive with its authentication key set and unknown, which is a different and much worse problem than the power pin; enterprise drives covers locked drives.

SAS: five generations, of which four are published

SAS runs the SCSI command set over a link that is electrically a close relative of SATA’s. The generation count is where most guides, including the earlier version of this one, are out of date.

SAS-1 is usually written as a 3 Gb/s generation, and that is how it was deployed, but ANSI INCITS 376-2003 defined both 1.5 and 3 Gb/s. A 1.5 Gb/s SAS drive is a real if rare thing to meet on the used market, and a link that trains at 1.5 Gb/s - 150 MB/s of payload once 8b/10b is paid for - is not necessarily faulty.

SAS-5 is further along than “proposed”. T10’s drafts page in September 2026 shows it at revision 4 dated 11 May 2026 with status “INCITS Approval” under project BSR INCITS 561 - through the technical work and in final approval, but not yet a published standard. Five generations are in flight, not four, and none of the five will be relevant to a used-drive buyer for years: the SAS drives on the used market are overwhelmingly SAS-2 and SAS-3.

It is worth knowing that “SAS” names several documents, because the one you want to cite depends on the question. The physical and architectural standard is the SAS-n series above. The protocol layer is separate: SPL-4 is ANSI INCITS 538-2018 and SPL-5 is ANSI INCITS 554-2023. The commands a SAS disk actually answers come from the block command set SBC-5 (ANSI INCITS 571-2025) and the primary command set SPC-6 (ANSI INCITS 566-2025) - those are the documents that define FORMAT UNIT and protection information, which matter later in this guide.

SAS-4 is the first generation with forward error correction

The odd 22.5 Gb/s figure is neither a typo nor marketing, and the reason is a change of line code.

SAS-1 through SAS-3 used 8b/10b and spent 20 per cent of the wire on it. SAS-4 moved to a 150-bit SPL packet built as 2 header bits + 128 payload bits + 20 FEC bits. Kioxia’s technical brief on its 24G SAS drives describes it as “128b/130b industry standard encoding, plus 20-bit FEC”, and states what the FEC buys: “it can detect and correct errors up to 20 bits long on-the-fly without requiring a retransmission.” Earlier SAS generations detected errors and asked for the frame again; SAS-4 is the first that repairs them in place. SAS-4 also adds an Adaptive PHY Training Algorithm, which tunes the link to the channel rather than assuming a nominal one.

overhead        (2 + 20) / 150               = 14.67%     (8b/10b: 20.00%)

payload rate    22.5 Gb/s x 128 / 150        = 19.2 Gb/s
                19.2 / 8                     =  2.4 GB/s  = 2,400 MB/s per lane
x4 wide port    2,400 x 4                    = 9,600 MB/s

against SAS-3   2,400 / 1,200                = exactly 2.00x

The signalling rate was chosen so that the payload doubled. Had SAS-4 kept 8b/10b, doubling the payload would have required 24 Gb/s on the wire; the better code bought back the difference. This is also why the marketing name is “24G” while the specification says 22.5 - the name rounds the signalling rate, and the number that matters is 19.2.

Full duplex is the SAS advantage nobody quotes

Here is a difference between SAS and SATA that almost never appears in a comparison table and is worth a factor of two.

SATA is half duplex. SAS is full duplex. A SATA link’s 600 MB/s is the total across both directions; at any instant the link is carrying data one way. A SAS lane carries its full payload rate in each direction simultaneously.

Kioxia states the consequence directly for 24G SAS against SATA 6Gb/s: “about four times the bandwidth (22.5 Gb/s vs 6 Gb/s), and about eight times the bandwidth when you consider that SAS is full-duplex versus SATA at half-duplex.”

Whether that second column is worth anything depends entirely on the workload. A backup that only writes, or a media server that only reads, never uses it. A storage node serving reads while replicating writes uses it constantly, and so does an array during a rebuild that is reading from survivors and writing to a replacement at the same time. For a home server with a mostly one-directional workload, full duplex is a specification you have paid for and will not use, which is part of why used SAS drives are cheap.

Wide ports, expanders, domains, and the second port

SAS’s real differences from SATA are topological rather than electrical.

Wide ports. Several lanes (“phys”) between the same pair of devices act as one logical port, and a single transfer can be striped across them. That is what the x4 column in the generation table means, and it is why an HBA has four-lane connectors rather than four one-lane ones.

Dual porting. A SAS drive presents two independent ports on one connector - physically the second contact set on the reverse of the same tongue - so two controllers can both reach it. This is how a dual-controller array survives a controller failure without losing access to a single disk. Each SAS port carries its own 64-bit SAS address, a World Wide Name normally in NAA IEEE Registered format, which is how the fabric distinguishes two paths to one drive from two drives. In a home server with one HBA, dual porting does nothing at all, and the second port sits idle.

Expanders. A SAS expander is a switch, and it is what the backplane in a used server chassis actually is: one four-lane HBA port feeds dozens or hundreds of drives that share that port’s bandwidth. There are two kinds and they have different limits. An edge expander communicates with up to 255 SAS addresses and does direct and subtractive routing; without a fanout expander present, at most two edge expanders may exist in a delivery subsystem. A fanout expander connects up to 255 edge expander device sets, does table and fanout routing, and does not do subtractive routing. A SAS domain can address up to 65,535 devices.

Those numbers explain the shape of real storage systems. A single shelf is an edge expander. A rack of shelves behind one controller pair is a fanout expander with edge expanders below it. Nothing in a home lab comes near the ceilings; what does bite is bandwidth sharing, which has its own section below.

Three protocols over one link. SAS carries SSP (Serial SCSI Protocol) for SCSI devices, STP (Serial ATA Tunneling Protocol) for SATA devices, and SMP (Serial Management Protocol) for managing the expander fabric itself. STP is the entire mechanism by which a SATA drive works behind a SAS controller, and there is no reverse of it, because a SATA host controller implements ATA and nothing else.

The SATA port multiplier, and the two kinds of host support

SATA’s nearest equivalent to an expander is the port multiplier, and it is much weaker in two separate ways.

The first is arithmetic. The port field is four bits, giving sixteen values, one of which is the multiplier’s own control port. Linux writes this down exactly: include/linux/ata.h defines SATA_PMP_MAX_PORTS as 15 and SATA_PMP_CTRL_PORT as 15. Fifteen fan-out ports, maximum, ever.

The second is the one that decides whether a cheap enclosure is worth buying, and it is rarely on the box. SATA-IO describes two kinds of host support:

• Command-based switching is “conceptually similar to a mechanical A/B switch, limits the host to issue commands to only one drive at a time … it does not take advantage of the potentially higher speed host link.”
• FIS-based switching lets the host issue and complete commands to any drive at any time, giving “aggregated throughput of up to the total bandwidth of the host band link.”

A controller that only does command-based switching gives you one drive’s worth of bandwidth no matter how many drives you put behind it. A five-bay enclosure on a command-based controller is a five-bay enclosure with the throughput of one drive, and nothing in the operating system announces this. A controller must support at least one of the two schemes for port multiplication to work at all, and many do not support either.

Linux adds a runtime warning worth knowing about: with link power management active on a fan-out port, hotplug does not work on fan-out ports and warm-plug is required. A drive swapped live behind a port multiplier may simply not appear.

The one-way rule, and why it is mechanical before it is logical

A SATA drive works on a SAS controller. A SAS drive does not work on a SATA controller. No cable changes this.

The forward direction works because SAS hosts implement STP and will wrap ATA commands for a SATA target. The reverse fails because a SATA host controller implements ATA and nothing else, while a SAS drive answers in SCSI - and a passive cable contains no translator.

The connector standard enforces it before the protocol gets a chance to. SFF-8482 (revision 2.5, “Serial Attachment 2X Unshielded Connector”) defines the device plug as three contact sets:

And then the sentence that is the whole rule: “the backplane fixed (receptacle) interface supports device free (plug) interfaces which have CS1 and CS3 only or has all CS1, CS2 and CS3 contacts.”

A SATA drive presents CS1 and CS3 only, with a physical gap where CS2 would be, and the SATA receptacle has a plastic bridge sitting in that gap. A SAS drive fills the gap with CS2’s contacts, making one continuous tongue. The SAS drive therefore cannot seat in a SATA receptacle - the bridge is in the way. The compatibility is asymmetric in plastic before it is asymmetric in protocol, which is unusually good standards design: the mistake that would fail silently is the one made physically impossible.

SFF-8482-to-SATA cables are sold as though they solved this. They plug into the drive, they plug into the motherboard, and they do not work, because nothing in the path speaks SCSI. The answer is a SAS HBA.

A few more details from the same specification, for anyone building rather than buying. The connector uses a three-level contact engagement sequence with offset key contacts so that hot-plug happens in the right order - grounds first, then power, then signal - and there are two dedicated sequencing pins in CS3 of the backplane receptacle. Mate force is specified at 25 N maximum for a backplane connector and 50 N for a cable connector, with unmate minimums of 5 N and 20 N. And: “there is no provision for positive mating interface retention latching in the backplane fixed version.” A backplane drive is held by its carrier, not by its connector, which is why a drive in a sled with a broken latch will walk out of the backplane under vibration.

One naming point that keeps guides confusing. SFF-8482 is the generic, legacy name in a family of mechanically compatible device connectors graded by speed, of which SFF-8680 is the 12 Gb/s member. SFF-8482’s own abstract grades the other two: SFF-8678 at 3 Gb/s and SFF-8681 at 24 Gb/s. Neither that ladder nor the others that circulate has a 6 Gb/s rung, and 6 Gb/s is the one generation a used-drive buyer is most likely to be holding, so treat any per-number speed mapping you meet as a claim to check. U.2’s SFF-8639 is an extension of SFF-8680. A 12G SAS drive’s connector is properly SFF-8680; everyone, this site included, calls it SFF-8482.

How far the cable goes, and why disk shelves are SAS

One specification difference explains an entire category of hardware. The figures usually quoted - they are widely repeated rather than drawn from a specification this guide can cite directly - are:

That is why external drive shelves are SAS and why there is no such thing as a SATA disk shelf. A shelf needs to sit in a different part of the rack from the server, and a metre does not reach. It is also why a cheap 2 m internal SATA cable on eBay is out of specification, and why a link that trains at 3 Gb/s on a long cable is behaving predictably rather than failing mysteriously.

The cable-length difference is also the reason the connector families fork by location rather than by speed alone. SFF-8643 is the internal Mini-SAS HD connector and SFF-8644 is the external one. They carry the same protocol at the same rate; the external version is shielded and latched for a cable run that leaves the chassis. Buying the wrong one is a common and cheap mistake, and they are not adaptable without a bulkhead.

The connector family tree, by role

Connector part numbers are the hardest thing to search for, because the listing, the chassis manual and the cable vendor each use a different name for the same thing. The useful organising principle is role: a connector is either on a device or on a host and cable.

Device side - what the drive itself presents:

Host and cable side - what the controller and the backplane present:

The progression across SAS generations is SFF-8087 to SFF-8643 to SFF-8654 and SFF-8621. A SAS-3 card with SFF-8643 ports will not accept a SAS-2 backplane’s SFF-8087 cable without an adapter cable, and the adapter cables exist and are cheap.

The cable traps the standard itself warns about

SFF-9402, “Multi-Protocol Internal Cable Pinouts for SAS and/or PCIe”, revision 1.1, is unusually candid about how bad this area is, and two of its warnings are worth quoting because they describe traps that a buyer meets in practice.

The first is that PCIe over Mini-SAS HD connectors is not a standard at all: “present PCI Express internal implementations using SFF-8643/8673/8654 connectors are vendor specific (Not standardized) … They do not align with SAS/SATA legacy SFF-8643/8673 implementations (Some range from 85 to 100 ohms; some have a white ring on fixed ends). As a result, PCIe cables utilizing SFF-8643/8673 connectors used for SFF-9402 can currently be plugged into legacy SAS/SATA implementations resulting in signal incompatibilities.”

Read that carefully: a PCIe cable and a SAS cable can share a connector, differ in characteristic impedance by up to 15 ohms, be distinguished only by a white plastic ring that some vendors use and others do not, and mate with each other without complaint. A white ring on the fixed end is a hint, not a standard.

The second is that cables have a direction. Section 8 of SFF-9402 is titled, in the specification’s own words, “Not Reversible Cables”, and note 5b says: “SAS hybrid cables only are no longer reversible such that they cannot be flipped between controller and backplane. Example: A SAS cable designed such that the controller end is Mini SAS HD and the backplane end is MiniLink cannot be used where the controller has MiniLink and the backplane with Mini SAS HD.” SAS-4 reassigned sidebands 2, 3, 4 and 5 and removed 8 and 9, which is why the generations diverge here.

That is the standards-body version of the trap everyone meets on eBay. Mini-SAS breakout cables come in forward (one host SAS port out to four SATA drives) and reverse (four motherboard SATA ports in to one SAS backplane connector) variants. They are visually identical, they are not interchangeable, and they are mislabelled constantly. A cable that fits, and is the right protocol family, and is the right generation, can still be the wrong pinout. Buy breakout cables from a seller who states forward or reverse explicitly, and expect to send one back.

HBA or RAID controller, and what IT mode actually changes

“Flashed to IT mode” appears in half the listings for used LSI and Broadcom cards and is rarely explained. The distinction is firmware, and it changes what the operating system sees.

IR firmware - Integrated RAID - is the factory default on many cards. It interposes a RAID layer: the card writes its own metadata to the drives, can present arrays as single volumes, and may not pass individual drives through cleanly. IT firmware - Initiator Target - turns the same card into a pure pass-through host bus adapter. Each drive appears to the operating system as itself, with its own serial number, its own SMART data and no metadata added.

Why it matters: ZFS-based stacks want raw drives. TrueNAS, Proxmox and Unraid all expect to see the disks directly, because their redundancy and checksumming assume they own the layout. A RAID layer between them and the media hides exactly the information they are designed to act on, and in the worst case caches writes the filesystem believes are on the platter.

The chipset determines the tool and the image, and the families a used-hardware buyer meets are:

Three warnings, in decreasing order of how much they cost.

• Existing firmware must be erased before a cross-flash. Writing an IT image over an IR image without erasing first is the standard way to brick a card into a state where it no longer enumerates on the PCIe bus and cannot be re-flashed from the same machine.
• A RAID controller in “JBOD mode” is not an HBA. JBOD mode on an IR-firmware card typically presents each drive as a single-disk RAID volume, with the card’s metadata on it and often with the card’s cache in front of it. It looks like pass-through in the disk list and is not pass-through underneath. Whether SMART passes through at all varies by card and firmware.
• Counterfeit and rebadged cards are common. The same silicon ships under LSI, Broadcom, Dell, HP, IBM, Supermicro, Intel and others, with vendor firmware that may refuse a generic image or may be locked. A card that arrives already flashed to IT is worth a small premium over one you must do yourself.

Enterprise drives goes further into what an HBA costs and what it buys against the price difference on the drives themselves.

The HBA’s own PCIe link is usually the bottleneck

This is the arithmetic almost nobody does, and it changes which card is worth buying.

An HBA has two links: the SAS ports facing the drives, and the PCIe slot facing the system. The card can deliver only the smaller of the two, and on the common used cards the PCIe side is smaller.

SAS-2 HBA, PCIe 2.0 x8
  host side   8 lanes x   500 MB/s   =  4,000 MB/s
  SAS side    8 phys  x   600 MB/s   =  4,800 MB/s
  deliverable                          4,000 MB/s   (83% of the ports)

SAS-3 HBA, PCIe 3.0 x8
  host side   8 lanes x 984.6 MB/s   =  7,877 MB/s
  SAS side    8 phys  x 1,200 MB/s   =  9,600 MB/s
  deliverable                          7,877 MB/s   (82% of the ports)

In both generations the card cannot deliver its own port bandwidth to the system. That is a deliberate design compromise rather than an error - the ports are oversubscribed on the assumption that not every drive is streaming at once - but it means an eight-port card in a x4 slot is halved again, and boards that share lanes will happily give you a x4 slot in a x8 socket.

Then extend the sum along the whole path, because the uplink between the backplane and the HBA is usually the real constraint:

one HC580-class drive, sustained                          298 MB/s
24 such drives streaming at once     24 x 298         = 7,152 MB/s
SAS-3 x4 backplane uplink            4 x 1,200        = 4,800 MB/s

oversubscription                     7,152 / 4,800    =    1.49 : 1
per-drive share at saturation        4,800 / 24       =     200 MB/s

A 24-bay SAS-3 shelf on a single x4 uplink is oversubscribed roughly one and a half to one for purely sequential work. That is invisible in every normal workload and decisive in exactly one: a full-array rebuild or scrub, which reads every drive at once for hours. A rebuild that you estimated from a drive’s 298 MB/s will run at 200. Rebuild arithmetic matters enough that drives for a NAS devotes a section to it; this is the term people leave out.

Two ways to spend money on that, if it turns out to matter: a second uplink cable where the shelf supports two, which doubles the uplink, or splitting the drives across two HBAs. Neither helps a workload that is not saturating the uplink, and most home workloads are not.

Sector sizes on enterprise pulls: 520, 528, 4104, 4160

A used SAS drive from an array very often arrives formatted with sectors that are not 512 bytes, and a drive reporting an unfamiliar number is not damaged.

The reason is T10 protection information, eight bytes appended to each logical block: a 2-byte logical block guard (a CRC), a 2-byte logical block application tag, and a 4-byte logical block reference tag. As the sg3_utils documentation puts it, “devices with 512 byte logical block size typically have one protection interval appended, making its logical block data 520 bytes long.”

512 data + 8 protection information   = 520 bytes
512 data + 16 (vendor extensions)     = 528 bytes
4096 data + 8                         = 4104 bytes
4096 data + 64                        = 4160 bytes

All four of those exist on real pulls. The 520 and 528 figures come from 512-byte-native array drives; 4104 and 4160 from 4Kn enterprise drives with protection information, which are increasingly what a recent pull is. A guide that only tells you to look for 520 will leave you confused by a drive reporting 4160, which is the same phenomenon with a different base.

An operating system that expects 512-byte or 4096-byte blocks will usually refuse the drive outright rather than misread it, which is the good outcome. Some controllers will show the drive with a nonsensical capacity instead.

Reformatting, and the state the standard calls format corrupt

The fix is a low-level reformat with sg_format from sg3_utils, and the man page contains the warning that actually matters:

sudo sg_format --format --size=512 --fmtpinfo=0 /dev/sg1

When the block size changes, this is not one command but two. “If the block size given by this option is different from the current value then a MODE SELECT command is used to change it prior to the FORMAT UNIT command … If the MODE SELECT command succeeds and the FORMAT fails then the disk may be in a state that the standard calls ‘format corrupt’.”

There is a window between those two commands in which a power loss or a reset leaves the drive in a state the standard has a name for. It is usually recoverable by running the format again, but it is a state you should know exists before you unplug something impatiently. The operation takes hours on a large drive and is not reversible mid-run.

The flags worth knowing:

sg_format gives a 15-second abort window before destructive operations, which is the last chance to notice you typed the wrong /dev/sg node. Unmount the drive first. And after a format that changes block size or block count, “the operating system may need to be told to re-initialize its setting for that disk” - a rescan or a reboot, not a fault.

There is one more manoeuvre, widely reported by people doing this and not documented in the sg3_utils man page or in any T10 material this site can cite: that some vendor-locked array pulls (NetApp, EMC and IBM drives are the ones named) will refuse a direct 520-to-512 reformat, and need reformatting to their existing 520-byte size first to clear the array controller’s lock, then immediately reformatting to 512. Treat that as folklore that often works rather than as a procedure. If the straightforward command fails on a vendor-branded drive, it is the next thing to try, and it is not guaranteed.

The NVMe version of the same problem

Enterprise NVMe pulls have the identical problem in different clothing, and the tool is different.

NVMe’s end-to-end data protection is, in the specification’s own words, “compatible with SCSI Protection Information, commonly known as T10 DIF, and SNIA DIX standards”. An NVMe namespace is formatted to one of several LBA Formats, each with an LBA data size and a metadata size, and the Format NVM command “changes the LBA data size and/or metadata size for the NVM media”.

So an enterprise NVMe drive out of an array can arrive with a non-default LBA format carrying metadata bytes, and it will be as unusable as a 520-byte SAS drive. The fix is nvme format selecting a different LBA Format index - not sg_format, which speaks SCSI to a device that does not. List the formats the namespace supports before choosing one; the drive publishes them, and the index you want is almost always the one with 512 or 4096 bytes of data and zero bytes of metadata.

NVMe: the queue numbers are correct and almost irrelevant

NVMe is a command set and register interface for non-volatile memory attached over PCIe. It replaced AHCI, which was designed in 2004 to drive a spinning disk through a single command engine.

The queue figures are worth getting right, because they are quoted wrongly everywhere including in the previous version of this guide. NVMe Base Specification revision 2.4 says the interface “includes support for parallel operation by supporting up to 65,535 I/O Queues with up to 65,535 outstanding commands per I/O Queue.”

Not 65,536. The specification explains the off-by-one itself, in section 3.3.3: “the maximum size for either an I/O Submission Queue or an I/O Completion Queue is defined as 65,536 slots … One slot in each queue is not available for use due to Head and Tail entry pointer definition.” A circular buffer whose head and tail pointers are equal is either full or empty, and the standard resolves the ambiguity by never letting it fill completely.

queue slots, maximum                          65,536
one slot lost to head/tail pointer definition     -1
outstanding commands, maximum                 65,535

queue size, minimum                                2 slots
Admin Submission and Completion queues, max    4,096 slots
queue identifiers                              1 to 65,535

None of that describes your drive. The real constraint is the controller, and the controller publishes it. CAP.MQES is the controller’s advertised maximum queue size - “this is a 0’s based value. The minimum value is 1h, indicating two entries.” And the Set Features command for Number of Queues carries an explicit warning that the host does not get what it asks for: “the value allocated may be smaller or larger than the number of queues requested … The controller may not have as many queues to allocate as are requested.”

A consumer NVMe SSD typically allocates a handful of queues and supports a maximum queue size far below 65,536. The spec’s ceiling is an architectural statement, not a product specification, and a desktop workload rarely leaves single-digit queue depths anyway.

What actually makes the command path cheap

The specification is clear about what it was designed to achieve, and it is not queue depth. Its stated goals are about the cost of issuing a command:

• “Does not require uncacheable / MMIO register reads in the command submission or completion path.”
• “A maximum of one MMIO register write or one 64B message is necessary in the command submission path.”
• “All information to complete a 4 KiB read request is included in the 64B command itself.”

Those three sentences are the whole performance argument. A submission queue entry is 64 bytes and a completion queue entry is 16 bytes, both in host memory. Submitting a command means writing 64 bytes into RAM and ringing one doorbell register. Zero uncacheable device reads. An uncacheable read across PCIe costs on the order of a microsecond and stalls the issuing core the entire time; AHCI’s command path touches several such registers per command.

Add the structural difference:

• A queue pair per CPU core, each with its own interrupt vector. Nothing is shared between cores, so nothing needs locking. AHCI’s single command list per port is a lock every core contends for.
• No rotating-disk assumptions in the command set: no cylinder geometry, a small mandatory command set and everything else optional.

None of this helps a hard drive, whose commands arrive slowly enough that a microsecond of register access vanishes into an 8.33 millisecond rotation.

The specification is now eleven documents

NVMe was refactored in version 2.0 from one specification into a family, and the current set is eleven documents:

The current Base revision as of September 2026 is 2.4, ratified 31 July 2026 and released 4 August 2026, superseding revision 2.3 released 5 August 2025. The companion revisions published alongside the 2.3 release were NVM Command Set 1.2, Zoned Namespaces 1.4, Key Value 1.3, Subsystem Local Memory 1.2, Computational Programs 1.2, PCIe Transport 1.3, RDMA Transport 1.2, TCP Transport 1.2, Management Interface 2.1 and Boot 1.3.

NVMe over Fabrics no longer has its own specification. NVM Express explicitly lists the standalone NVMe-oF document as obsolete, kept only “as a historical reference”; fabrics now live in the Base specification plus the RDMA and TCP transport specifications. This is the part of the earlier claim that NVMe “runs over Ethernet between machines” that has a document behind it: NVMe over TCP is a transport binding in the same family as NVMe over PCIe, not a separate protocol.

For a used-drive buyer, none of the revision numbers matter directly. What matters is that an NVMe drive’s feature set - the SMART log, the self-test log, namespace management, the format command - is standardised across vendors in a way SATA’s never was, which is why reading wear off an NVMe drive is easy and reading it off a SATA SSD is a minefield. SSD endurance works through both.

NVMe hard drives are standardised, and it was never about speed

The earlier version of this guide said NVMe hard drives “have been demonstrated and are being standardised”. That tense is now wrong.

NVMe Base Specification revision 2.4 has a normative section titled “Rotational Media” - numbered 8.1.25 as of revision 2.3, and worth re-checking against whichever revision you have, because the subsections of 8.1 are ordered alphabetically and renumber whenever one is added. A controller that supports rotational namespaces shall set the Rotational Media bit in NSFEAT, shall support the Rotational Media Information log page, shall support the Spinup Control feature, and shall support Endurance Groups. The log page, identifier 16h, carries Number of Actuators, Nominal Rotational Speed in RPM, Spinup Count, Failed Spinup Count, Load Count and Failed Load Count.

Read that list of fields. It is a hard drive’s vocabulary: actuators, RPM, spin-up attempts, head load cycles. The NVMe specification now has a place to report that a drive has two actuators and spins at 7200 RPM, which is not something a protocol designed for flash would carry by accident.

The conclusion in the earlier version was right and survives: the argument for NVMe hard drives is protocol unification, not speed. A data centre that can address every device behind one command set, one driver stack and one management interface saves real money in software. The drive underneath still delivers 298 MB/s sequential and 212 IOPS random, and no amount of command-path efficiency moves a head faster. You will not meet one on the used market for years.

PCIe: two encoding breaks, not one

PCIe is the bus under every NVMe drive, and its per-lane throughput is derivable from two numbers: the signalling rate and the line code. It has changed line code twice, in opposite directions, and both changes are visible in the table.

The first break was at generation 3. Moving from 8b/10b to 128b/130b cut the line-code cost from 20 per cent to 1.54 per cent, which is why generation 3 nearly doubled generation 2 while raising the signalling rate only 1.6 times.

PCIe 4.0, one lane:  16 GT/s x 128 / 130 = 15.754 Gb/s
                     15.754 / 8          =  1.969 GB/s
four lanes:          1.969 x 4           =  7.877 GB/s = 7,877 MB/s

Gen2 -> Gen3 per lane: rate  8 / 5           = 1.60x
                       code  0.9846 / 0.80   = 1.23x
                       total                 = 1.97x

The second break was at generation 6, and it goes the other way. PCIe 6.0, published in January 2022, replaced NRZ signalling with PAM4 - four voltage levels per symbol instead of two, so two bits per symbol - and replaced the encoding with a fixed 256-byte FLIT carrying 242 bytes of payload, an 8-byte CRC and 6 bytes of forward error correction. PAM4’s smaller eye opening makes errors more likely, so the FEC is not optional; it is what makes the signalling rate usable.

FLIT structure     242 payload + 8 CRC + 6 FEC       = 256 bytes
overhead           14 / 256                          = 5.47%
                   (128b/130b was 1.54%)

per lane           64 GT/s x 242 / 256 / 8           = 7,562.5 MB/s
against PCIe 5.0   7,562.5 / 3,938                   = 1.92x, not 2.00x

So generation 6 does not quite double generation 5, and the missing 4 per cent is the price of the error correction that makes PAM4 work at all. This is the same trade SAS-4 made, in the same years, for the same reason.

Where the standard is now: PCI-SIG released the PCIe 7.0 specification to members on 11 June 2025 at 128 GT/s, which its announcement puts at up to 512 GB/s bidirectionally on a x16 link, again using PAM4 and FLIT mode. PCI-SIG announced PCIe 8.0 on 5 August 2025, targeting 256 GT/s and up to 1 TB/s bidirectionally on x16, planned for release to members by 2028. Neither will appear in a consumer SSD for years; both are being driven by accelerator interconnect rather than storage.

The practical consequence for buying is that drives cluster at bus ceilings. Gen3 x4 flagships all advertised about 3,500 MB/s. Gen4 x4 drives all advertise about 7,400. Gen5 x4 drives cluster near 14,500. Those are bus ceilings minus protocol overhead, not product differences, and comparing two drives of the same generation on their headline sequential number tells you almost nothing.

Lanes are the other half, and boards mislead by omission

A consumer NVMe SSD is x4; some budget drives are x2, and the listing rarely says. A Gen4 drive in a Gen3 slot negotiates down and works. A x4 drive in a slot wired x2 also works, at half the bandwidth, with nothing announcing it. So ask the hardware:

$ sudo lspci -vv -s 01:00.0 | grep -E 'LnkCap|LnkSta'
        LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
        LnkSta: Speed 16GT/s, Width x4, TrErr- Train- SlotClk+ DLActive-

LnkCap is what the device can do; LnkSta is what it negotiated. A mismatch between the two is the thing to look for, and it has three usual causes: the slot is wired narrower than it looks, the board has reallocated lanes because another slot is populated, or the link trained down because of a marginal riser.

Boards share lanes between slots - populating a second M.2 commonly disables SATA ports or drops the graphics slot to x8 - and which are shared is entirely per-board. The block diagram in the manual is the only authority; there is no general rule here. A chipset-attached M.2 slot also sits behind the link between the chipset and the CPU, which is itself a PCIe link of finite width shared with everything else on the chipset, so two chipset-attached drives can contend with each other and with USB and networking in a way two CPU-attached drives do not.

M.2 is a card standard, and the key is a statement about plastic

M.2 is a card form factor with a family of notch positions. The notch, or key, restricts which sockets a card can enter. Three of the five concern storage.

Note the A and E rows carefully: those are two separate PCIe x1 links, not one x2 link. A wireless card wants two independent narrow links, not one wider one.

The specification names sockets as well as keys, and a motherboard manual that mentions a socket number is telling you the keying: Socket 1 accepts A-key and E-key cards, Socket 2 accepts B-key cards, Socket 3 accepts M-key cards. “M.2 Socket 3” in a manual means M-keyed.

Two dates worth having, because they explain why M.2 is a joint creature: M.2 is defined by the PCI-SIG M.2 specification, revision 1.0, November 2013, and SATA revision 3.2 in August 2013 is what standardised M.2 as a SATA form factor. The connector belongs to PCI-SIG; the SATA signalling over it belongs to SATA-IO.

Now the thing that catches people, and it is worth stating in the specification’s own terms rather than the market’s. A key says which signals the connector may route, not which the board behind it or the controller on the card actually implements. Two failures follow, both presenting as a drive absent from the BIOS.

An M-key NVMe drive in a SATA-only M.2 socket. It slides in, screws down, and does not exist. Common in mid-2010s laptops, and still found on the secondary socket of some low-end boards.

A B+M-keyed SATA drive in an NVMe-only M.2 socket. Same outcome, opposite direction. Plenty of current boards route only PCIe and document SATA support nowhere, because they have none.

The useful heuristic is that almost all M.2 NVMe SSDs are M-key only, and almost all M.2 SATA SSDs are B+M keyed - but be clear about what kind of statement that is. It is a market convention, not a rule in the standard. The M key may legally carry SATA; the specification says so. Vendors key SATA drives B+M for the widest socket compatibility and key NVMe drives M-only because the fourth PCIe lane needs the M-key pins. Two notches is a strong hint of SATA and not proof - B+M was also used for PCIe x2 NVMe drives - so confirm against the vendor’s page for the part number, not the eBay title.

Lengths, widths and thickness classes

Length is coded as width then length in millimetres:

Read 22110 as 22 wide by 110 long, not 221 by 10. The extra 30 mm is usually a bank of power-loss-protection capacitors, which is why it is an enterprise form factor. A socket has standoff positions only for the lengths it supports. The specification also defines 12 mm, 16 mm and 30 mm card widths, which you will essentially never meet in storage.

Thickness is a specified dimension rather than the loose “single- or double-sided” the market uses. The specification defines single-sided classes S1 to S3, allowing 1.20 to 1.50 mm of components on the top only, and double-sided classes D1 to D5, allowing 1.20 to 1.50 mm on top plus 0.70 to 1.50 mm underneath. The PCB itself is 0.8 mm, plus or minus 10 per cent.

That matters because thin laptops, some NAS bays and several console slots have clearance for one side only, and a double-sided 2280 card will either not fit or will fit with its underside pressed against the board. If a machine’s manual specifies a thickness class, it is telling you something enforceable.

M.2 has no 12 volt rail

M.2 is a 3.3 V-only form factor. SNIA’s EDSFF comparison material lists M.2 power simply as “3.3V”, against E1.S’s “12V and 3.3V”. U.2 (SFF-8639) is rated up to 25 W at 15 mm thickness; E3.S goes to 40 W at 16.8 mm.

Two consequences follow directly.

The first is why M.2-to-U.2 adapters need an external power feed. A U.2 drive may draw up to 25 W and expects 12 V; the M.2 slot has neither the rail nor anything like the budget. An adapter that claims to power a U.2 drive from an M.2 slot alone is either lying or is relying on the specific drive being far under its class limit.

The second is thermal. Everything an M.2 drive dissipates has to leave through 3.3 V-fed silicon in a 22 mm-wide envelope with no airflow of its own, which is why high-end M.2 drives ship with heatsinks and why EDSFF exists at all. The power ladder from M.2 through U.2 to E3.L is the real story of why servers left M.2 behind.

U.2, U.3, and the direction the specification actually promises

U.2 is the SFF-8639 connector on a 2.5-inch drive, usually 15 mm thick, carrying PCIe x4 to an NVMe drive. The connector is a deliberate superset - the same receptacle can be wired for SATA, SAS or PCIe - which is why it looks like SAS, and why the backplane wiring decides what a U.2 bay does, not the plug.

U.3 is SFF-TA-1001, and the earlier version of this guide had its compatibility backwards. The specification is titled “Universal x4 Link Definition for SFF-8639” and its Scope states the direction without ambiguity:

“This specification does not mandate nor imply any SFF-TA-1001 slot compatibility with Quad PCIe devices. This specification does mandate that SFF-TA-1001 devices are compatible with both Quad PCIe slots and SFF-TA-1001 slots.”

In plain terms: a U.3 drive in a U.2 bay is required to work. A U.2 drive in a U.3 bay is not. The specification’s Table 1-1 lists every Quad PCIe device - which is what a conventional U.2 drive is - in an SFF-TA-1001 slot as “No link”.

An independent test-equipment vendor confirms the same direction from the implementer’s side: Quarch’s write-up states that “U.3 drives are still backward compatible with U.2” and that “U.2 drives are not compatible with U.3 hosts” because the data lane pinouts do not match, and that the drive reads the HPT0/HPT1 Host Port Type pins at power-up to work out which kind of host it is in and configures its lanes accordingly.

Chassis vendors do ship U.3 backplanes that accept U.2 drives, by adding routing the baseline does not require. That is a vendor feature, not a specification guarantee, which is why the practical advice survives the correction unchanged: check the chassis vendor’s own drive compatibility list by part number before buying U.2 drives for a U.3 machine. The risk now points the other way from what this guide previously said.

How a U.3 bay works out what you plugged into it

The detection is three sideband pins, and the encoding is published, which makes it possible to reason about a failure rather than guess at it. The pins are PRSNT# at P10, IfDet# at P4, and IfDet2# at E6, and SFF-TA-1001’s Table 4-8 gives the device type encoding:

The specification also notes that “No link instances can be detected by out of band signal (IFDET2) usage” - meaning a U.3 backplane can at least know that a U.2 drive has been inserted and report the mismatch, rather than leaving you staring at an empty slot with no explanation. Whether a given chassis surfaces that in its management interface is up to the vendor.

The mechanism by which U.3 gets PCIe onto SAS wiring is worth one paragraph, because it explains an otherwise strange requirement. SFF-TA-1001 says: “a standard SAS backplane construction may take advantage of the HPT0 (S15) signal pin to indicate the device slot is SFF-TA-1001. When an SFF-TA-1001 PCIe device is installed in such a backplane, the device responds to the SFF-TA-1001 slot indication and communicates on the SAS0/SAS1 lanes.” PCIe is remapped onto the lanes a SAS backplane already has, which is the entire commercial point: an existing backplane design can be adapted rather than redesigned.

The catch is that a SAS backplane routes neither a PCIe reference clock nor PERST#. So such a design needs either an SRIS-capable drive - Separate Reference Clock with Independent Spread, which lets the endpoint run from its own clock - or added REFCLK and PERST# routing on the backplane. A U.3 drive that does not support SRIS will not work in a backplane that relies on it, and this is not visible from the outside.

EDSFF: the drives you can buy and cannot use

E1.S, E1.L, E3.S and E3.L are the EDSFF family, which is what replaced M.2 and U.2 in new servers: better airflow, real hot-swap, and a power budget several times M.2’s.

E1.L is the one usually called “the ruler”, for obvious reasons at 318.75 mm long.

That fourth column needs a caveat the table cannot carry. The per-thickness wattages in the E1.S and E1.L rows are SNIA’s EDSFF comparison material, not the SFF-TA documents named beside them. What SFF-TA-1006 and SFF-TA-1007 define is an initial slot power limit - 12 W for the thinnest E1.S classes and 25 W above them, 25 W for E1.L - with no per-thickness ladder and no maximum sustained power specified at all beyond what the connector’s contacts will carry. The E3 rows are the specification’s own figures. The distinction matters the moment an adapter vendor quotes one of the marketing numbers at you as though a standard guaranteed it.

Lane width is set by the connector variant, defined in SFF-TA-1002: 1C is x4, 2C is x8, 4C is x16. E1.S is 1C or 2C; E3.S can be 4C. U.2’s SFF-8639 tops out at x4 for PCIe, which is one of the reasons EDSFF exists - there was no way to give a 2.5-inch NVMe drive sixteen lanes.

The specifications are live documents and the family is still growing. SFF-TA-1002 is at published revision 1.6a dated 16 May 2025 and SFF-TA-1009, which carries the pin and signal definitions, at published revision 4.1a dated 4 May 2025. SFF-TA-1008 (E3) is at published revision 3.0a dated 10 July 2026. SNIA added SFF-TA-1042, “Enterprise and Datacenter 2U Form Factor (E2)”, published as revision 1.0 on 16 June 2025, and initiated a new project, SFF-TA-1049, “Hybrid E3 1C EDSFF SSD Connection”, on 17 July 2026.

You meet EDSFF exactly once as a home buyer: as decommissioned enterprise SSDs at a very good price per terabyte, which you cannot use, because the carrier, backplane and chassis do not exist outside a server. A few E1.S adapters exist. Treat a cheap EDSFF drive as unusable until you have found the specific adapter, by part number, and confirmed its power delivery - a 25 W E1.S drive is not going to run off a slot-powered adapter card that was designed for a 12 W one.

PATA: 40 pins, 80 conductors, and a wall at 137 GB

IDE, properly PATA, is a 40-pin parallel connector on 3.5-inch drives and a 44-pin one on 2.5-inch drives, the extra four carrying power.

The 40-conductor and 80-conductor cables have the same 40 pins. The 80-conductor cable interleaves a ground wire between every signal wire to suppress crosstalk, and it is required for every UDMA mode above UDMA/33 - that is, for ATA/66, ATA/100 and ATA/133. The host detects it through pin 34, which an 80-conductor cable grounds at the motherboard end. Without that ground the system silently clamps the drive to 33 MB/s:

$ dmesg | grep -i cable
ata1.00: limited to UDMA/33 due to 40-wire cable

$ sudo hdparm -I /dev/sda | grep -i udma
           DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

The asterisk marks the active mode. An 80-conductor cable is colour-coded, and the order is not decorative: blue to the motherboard, black to the end connector (drive 0), grey to the middle.

Jumpers set Master, Slave or Cable Select. The trap is vendor-specific: Western Digital drives distinguish “single drive” (no jumper) from “master with a slave present” (jumper fitted), where most vendors treat master and single as one setting. A WD drive jumpered as master, alone on the cable, may not be detected.

The capacity walls are arithmetic, and they explain why an old machine reports a wrong size rather than an error:

28-bit LBA (ATA-1 through ATA-5):
  2^28 sectors           =     268,435,456
  x 512 bytes            = 137,438,953,472 bytes
                         =         137.44 GB   (exactly 128.0 GiB)

CHS addressing ceiling:
  16,383 x 16 x 63 x 512 =   8,455,200,768 bytes
                         =          8.455 GB

48-bit LBA arrived with ATA-6 and moved the ceiling to 128 PiB, which is out of reach of anything that will ever be built on this interface. A controller or BIOS predating it truncates or wraps a larger drive, silently - and a wrapped drive that appears to work will corrupt itself the moment it passes the wall.

Both of those numbers are worth reading against the decimal-versus-binary confusion in drive capacity explained: the 137 GB wall and the 128 GiB wall are the same wall, described in the two unit systems that cause most of the arguments about drive size.

As for value: a working period-correct IDE drive is often worth more to somebody restoring a 1990s machine than it is as storage, and price per terabyte is a meaningless measure of it. That is a collector’s market, not this one - and since most restorers now fit CompactFlash or SD-to-IDE adapters, what a genuine drive is bought for is authenticity and the correct noise, not capacity or reliability from a mechanism twenty-five years old.

Adapters: wire, bridge, or nothing

If both ends speak the same protocol at the same signalling, the adapter is wire. If they do not, the adapter is a computer, and you should price and judge it as one.

Three warnings inside that table.

Breakout cables have a direction, as SFF-9402 says in a section title. Forward breakout runs one host SAS port out to four SATA drives; reverse runs four motherboard SATA ports into one SAS backplane connector. They look identical.

M.2-to-U.2 needs power. M.2 supplies 3.3 V only; U.2 drives expect 12 V and may draw up to 25 W. A working adapter has a separate power input, usually SATA or Molex. One without it will run some drives and not others, with no warning which.

A passive four-drive M.2 card in a x16 slot needs PCIe bifurcation - the board splitting that slot into x4/x4/x4/x4. Without it, only the first drive appears. Cards with a PCIe switch chip work in any slot, cost several times as much, and run hot. The board manual, not the card listing, decides which you need.

Impossible, whatever the listing says:

• SAS drive on a SATA controller. The host speaks ATA, the drive SCSI, and the connector will not seat in any case.
• M.2 SATA in an NVMe-only socket, or M.2 NVMe in a SATA-only socket. One end is a SATA PHY, the other a PCIe PHY. No passive card bridges that.
• NVMe drive on a SATA port. Same reason, more obviously.

Not impossible but not promised: a U.2 drive in a U.3 backplane. SFF-TA-1001 mandates no link at all in that direction, and only the chassis vendor’s own compatibility list settles whether a particular backplane adds the routing the baseline leaves out.

Where something does exist it is a bridge controller - a SATA-to-PCIe or USB-attached chip - with its own firmware, its own bugs, and its own effect on whether SMART and TRIM pass through.

When the bridge will not pass SMART

This one matters commercially, because it decides whether a used drive’s health can be checked at all inside the return window.

USB and IEEE 1394 storage devices “use the SCSI command set externally but almost always contain ATA or SATA disks (or flash)”, as smartmontools’ documentation puts it. Something has to translate, and the standard for it is SAT - SCSI to ATA Translation - implemented by a SCSI to ATA Translation Layer in the bridge chip. SAT provides two routes: an optional ATA PASS-THROUGH SCSI command, in 12-byte and 16-byte variants, and a translation from the closest equivalent SCSI command.

A bridge that implements neither, or implements pass-through incompletely, returns no SMART data at all. That is not a fault in the drive and not a fault in smartctl. It is a chip that was built to move files.

smartctl’s -d option is how you work around it when a workaround exists:

-d auto guesses from the device name, the operating system’s controller information, or a matching USB vendor and product ID in smartmontools’ own drive database. When it guesses wrong, naming the bridge type explicitly is the fix.

The buying consequence: if you are going to check used drives over USB, buy an enclosure whose bridge chip is known to pass SMART, and test it on a drive you already trust before you need it. Buying used drives on eBay is about what to do with the SMART data once you have it; this is about being able to get it at all.

Forcing the issue from the kernel command line

Linux’s libata has a documented escape hatch for several of the failure modes in this guide, and it is worth knowing that it exists before concluding that hardware is broken. The libata.force= kernel parameter can:

• Force cable type: 40c, 80c, short40c, unk, ign or sata. This is the fix for a PATA drive clamped to UDMA/33 by a cable-detect pin that is not grounded, when you are certain the cable really is 80-conductor.
• Limit SATA link speed: 1.5Gbps or 3.0Gbps. Note the direction - it can only limit downward, never force a link up to 6 Gb/s. Dropping a flaky link to 3 Gb/s deliberately is a legitimate diagnostic and sometimes a legitimate fix.
• Force a transfer mode: pio[0-7], mwdma[0-4], udma[0-7], with udma[/][16,25,33,44,66,100,133] notation also accepted.
• Toggle queuing and trim: [no]ncq, [no]ncqtrim, [no]trim. Disabling NCQ on a drive with buggy firmware is an old and still-current remedy.

None of these make a drive work that physically cannot. They make a drive work that the kernel has conservatively decided not to trust, which is a different and much smaller category, and every one of them is a deliberate decision you should be able to justify.

What to do with this on a listing page

1. Decide what the socket speaks before you decide what to buy. Not what it fits. For M.2 the board manual says “PCIe 4.0 x4”, “SATA and PCIe”, or “SATA only” - three different sockets behind one piece of plastic. Then filter NVMe SSDs or all SSDs accordingly rather than sorting by price and hoping.
2. For a hard drive, stop reading the interface field. One drive uses under half a SATA 6Gb/s link sequentially and 0.14 per cent of it randomly. Spend the decision on capacity, recording technology and hours instead - start at 3.5-inch hard drives and add drives stated as CMR if the drive is going into an array.
3. If it is SAS, price the HBA into the purchase. A SAS drive with no controller is not cheap storage, it is a paperweight plus a shopping list: an HBA, a PCIe slot, the right breakout cable in the right direction, and probably a sg_format run measured in hours.
4. Assume an enterprise SATA pull will need a Molex adapter, and buy one with the drive rather than after concluding it arrived dead. If the listing shows the label, read the model number: on a WD Ultrastar, the second-to-last character is the pin 3 configuration.
5. Assume an enterprise SAS or NVMe pull is in the wrong sector format until the seller says otherwise. 520 and 528 on 512-byte drives, 4104 and 4160 on 4Kn ones, and a non-default LBA format on NVMe. All are fixable; all take time; none is a fault.
6. For U.2, U.3 and EDSFF, confirm the carrier and backplane exist for your chassis, by part number, before the drive does. And remember the direction the standard actually promises: U.3 drives go into U.2 bays, not the reverse.
7. Check the negotiated link on arrival, not the advertised one - smartctl -i for SATA, lspci -vv for NVMe, inside the return window rather than after it. A drive that trained at 3 Gb/s or a x4 drive running x2 is a return, and it is only a return while the clock is still running.
8. Before you rely on a USB enclosure to vet a used drive, prove it passes SMART on a drive you already know. An enclosure that returns nothing has cost you the one check that the whole purchase turned on.

The interface rarely decides whether a purchase is good - capacity, recording technology and hours on the clock do far more, which is what buying used drives on eBay is about. What it decides is whether the drive works at all on the day it arrives, and that is a question you can settle completely, from published specifications, before spending anything.