Enterprise drive pulls: cheapest per terabyte, and what they need
By Harry Saarinen ·
Usually yes, if you have somewhere to put them. Enterprise pulls sit at the top of every price-per-terabyte sort on this site for a supply reason rather than a quality reason: the drives are fine, and almost nobody outside a rack wants one.
“Somewhere to put them” is the longer half of that sentence. A SAS drive will not enter a motherboard SATA port. A drive pulled from a NetApp may report zero capacity until you spend a day reformatting it. A drive pulled from an array that used its encryption may enumerate perfectly and refuse to return a single byte, with no way to tell that from a dead one unless you know what to ask. An enterprise SATA drive may refuse to spin up on a modern power supply for reasons that have nothing to do with the drive. All of it is solvable, most of it is free, and none of it is in the listing.
What follows is the mechanism behind each of those, with the vendor specifications the figures come from named in the text, so you can tell a published number from one this article derived.
Why they are cheap is a depreciation schedule, not a verdict
Datacentres retire storage on a calendar, not on failure. A fleet is decommissioned as a fleet - thousands of identical drives leaving service in one movement, wiped, palletised and sold on in bulk. The drive that arrives was not singled out for being marginal. It was in a rack that hit its depreciation date.
That date has moved, and it changes what arrives on the market. The useful life the hyperscalers assign to server hardware is a disclosed accounting estimate, printed in each company’s own annual report, and all three of the largest extended it. Alphabet moved servers from four years to six effective in its 2023 financial year; Microsoft extended cloud server and network equipment from four years to six in its fiscal 2023; Amazon went from three years to four in 2020, to five in 2022, and to six effective January 2024, then in early 2025 cut a subset back from six to five, citing the pace of development in artificial intelligence and machine learning. Each of those changes is quantified in the Form 10-K that discloses it, and the filing is where to read the amount. An earlier version of this section carried two industry-wide dollar figures with no document named behind either of them; they are gone, because a number nobody can check is not evidence.
Three consequences follow for a buyer:
- The typical pull is older than it used to be. A fleet leaving service after six years has 52,560 power-on hours rather than the 35,040 of a four-year cycle. Hours alone are a weak signal, which the next two sections are about, but the distribution has shifted and the listings reflect it.
- The capacities are larger. Six-year-old kit retired in 2026 was bought around 2020, which is 12 TB and 14 TB territory rather than 4 TB.
- The supply is lumpier. A longer cycle means fewer, larger decommissioning events, so a model can be abundant for a quarter and gone afterwards.
Underneath that sits a price environment that has stopped behaving. The VDURA Flash Volatility Index reported in August 2026 that 30 TB class hard drives had risen 2.45 times in a year, while new 30 TB TLC SSDs rose 6.5 times, leaving new flash at 18.6 times the price per terabyte of a new hard drive - down from a peak of 23.2 times, which tells you how violent the move was. Kingston reported NAND wafer prices up 246 per cent since the first quarter of 2025, against NAND being roughly 90 per cent of an SSD’s bill of materials. Used supply does not track any of that, because secondhand volume follows decommissioning schedules rather than wafer contracts, which is why the gap between new and used widened rather than closed. Whatever the ratio is on the day you read this, take it from the listing pages rather than from any article, this one included.
The workload rating is a rate, and the vendor publishes the formula
Five years of continuous service is 24 x 365 x 5 = 43,800 power-on hours,
which against a five-year design life looks spent. Against the workload rating on
the same datasheet it usually is not.
Seagate’s own knowledge base gives the definition, and it is arithmetic rather than a slogan:
Workload Rate = TB transferred x (8,760 / recorded power on hours)
Seagate's longer form, from the same document:
(Lifetime Writes + Lifetime Reads) x (8,760 / Lifetime Power On Hours)
Two things in that formula do real work. Reads count, which surprises people who have internalised SSD endurance, where only writes wear anything. And it is annualised, so a drive that ran for six months and moved 100 TB has a workload rate of 200 TB/year, not 100.
The nearline limit is a maximum rate of less than 550 TB per year, stated on the Seagate Exos X24 product manual and on Western Digital’s Ultrastar DC HC580 product manual in the same words: the workload can be made up of reads, writes, or both. Seagate’s lighter nearline tier, Terascale, is specified at less than 180 TB per year instead, which is a reminder that “enterprise” on a label is not one number.
Converting the rate to a sustained equivalent is where its size becomes obvious:
550 TB/year / 8,760 h = 62.79 GB/hour
62.79 GB/h / 3,600 s = 17.44 MB/s, averaged across the whole year
That rating is a 17.4 MB/s average, not a cap. A drive sustaining 250 MB/s would spend a full year’s allowance in about 25 days. Archive tiers, replicas and backup targets never come close, so a five-year pull can have used a fraction of its rated workload while using all of its calendar life. That gap is the reason this market exists, and the thin bidding is the rest of it: a 12 TB SAS drive is no good in a desktop, a laptop or a USB enclosure.
What exceeding it actually does
Not what the folklore says. Seagate’s position is that the warranty policy does not change, while reserving the right to limit warranty claims where drive usage exceeds specifications. Western Digital is more specific about the mechanism: the HC580 manual states an annualised failure rate of 0.35 per cent based on typical workload at 40 degrees Celsius device-reported temperature, and then that derating of the AFR will occur above those parameters, up to 550 TB/year workload and 60 degrees Celsius device-reported temperature.
Read that carefully, because it inverts the usual reading. The failure rate is not a constant that a workload limit protects. It is a function, and the published figure is its value at one point on a surface whose axes are workload and temperature. The 550 TB/year number is the edge of the region the vendor has characterised, not a cliff at which something breaks.
Computing the rate for a drive in front of you
The SCSI error counter log carries lifetime gigabytes processed on both rows, and
the background scan results log page carries accumulated power-on time, so
Seagate’s formula can be evaluated directly from one smartctl -a run. Using the sample
output shown later in this article:
read 98,765.432 GB
write 12,345.678 GB
total 111,111.11 GB = 111.11 TB
power on hours 43,970
workload rate = 111.11 x (8,760 / 43,970)
= 111.11 x 0.19923
= 22.1 TB/year
against the 550 TB/year specification 4.0%
Four per cent of the rated rate, one hundred per cent of the rated calendar life. That is the shape of a good pull, and it is the single most useful number you can compute from a seller’s SMART screenshot. The arithmetic is mine; the formula and the 550 figure are Seagate’s.
The reliability figure is valid only inside an envelope your case does not meet
Every listing that mentions 2.5 million hours MTBF is quoting a number with conditions attached, and the conditions are the interesting part. The Exos X24 SAS product manual states that the drive shall achieve an annualised failure rate of 0.35 per cent, equivalent to an MTBF of 2,500,000 hours, over a five-year service life, limited by the following:
| Condition | Specified value |
|---|---|
| Power-on hours | 8,760 per year |
| Drive-reported HDA temperature | 30 degrees Celsius or below |
| Ambient wet bulb | 26 degrees Celsius or below |
| Workload | typical, as defined by the workload rate |
| Gaseous contamination | ANSI/ISA S71.04-2013 severity level G2 |
| Airborne particulates | ISO 14644-1 Class 8 |
The temperature line is the one that matters domestically. A drive-reported temperature ceiling of 30 degrees Celsius is a datacentre cold aisle, and a 3.5-inch drive in a desktop case with one slow intake fan routinely reports the high thirties or low forties. That does not make the drive fail; it makes the quoted failure rate inapplicable, and neither vendor publishes the derating curve.
Note that the manual states that line as a ceiling rather than as a range. An earlier version of this table gave it as 10 to 30 degrees, which borrows the lower bound from the operating range printed elsewhere in the same document and credits the reliability envelope with a floor it does not set. The argument here only ever needed the ceiling.
The other two lines are not decoration either. G2 is a corrosion classification, and Class 8 is a particulate count. A drive is not hermetically sealed unless it is a helium drive, so the air in the room passes through it.
Both vendors then say the part nobody quotes. Seagate: the AFR or MTBF is a population statistic not relevant to individual units. Western Digital, in the HC580 manual: AFR ratings do not predict an individual drive’s reliability and do not constitute a warranty. Those are not disclaimers bolted on by lawyers. They are a statement about what kind of number it is, and it converts to an individual probability only under an assumption of constant hazard that the field data in a later section does not support.
The conversion itself is worth showing, because the two figures are one figure:
AFR = 1 - exp(-8,760 / MTBF)
~ 8,760 / MTBF for small AFR
8,760 / 2,500,000 = 0.00350 = 0.35% Exos X24 nearline, as published
8,760 / 0.0044 = 1,990,909 hours the MTBF implied by the 0.44% AFR
Seagate publishes for Exos 10E2400
and 15E900 - my arithmetic, not a
figure from the datasheet
What “enterprise” actually buys, line by line
| Specification | Enterprise nearline | Mission-critical 10K/15K | Typical consumer |
|---|---|---|---|
| Duty cycle | 24x7 continuous | 24x7 continuous | 8x5, or unrated |
| Workload rate | less than 550 TB/year | not on the datasheet | 55 TB/year, or unstated |
| Unrecoverable read errors | 1 per 10^15 bits | 1 per 10^16 bits | 1 per 10^14 bits |
| Published AFR | 0.35% | 0.44% | rarely published |
| Rotational vibration | 12.5 rad/s squared, 20 to 1500 Hz | not on the datasheet | not published |
| Load/unload cycles | 600,000 minimum | not on the datasheet | 300,000 to 600,000 |
| Start/stop cycles | 50,000 minimum | not on the datasheet | often unstated |
| Maximum capacity | 24 TB and beyond | 2.4 TB (10K), 900 GB (15K) | 24 TB and beyond |
Figures in the first two columns are from the Seagate Exos X24 SATA and SAS product manuals, the Exos 10E2400 and Exos 15E900 datasheets, and the Western Digital Ultrastar DC HC580 product manual. The consumer column is deliberately vaguer, because the specifications there are vaguer.
Four cells in the mission-critical column say “not on the datasheet”, and that is the vendor’s gap rather than this article’s. The 10E2400 and 15E900 datasheets publish capacity, latency, sustained transfer rate, cache, disks and heads, interface rate, nonrecoverable read errors, AFR, warranty, power, ambient temperature, shock and linear vibration. There is no TB-per-year workload row on either, no rad/s squared rotational vibration figure, and no load/unload or start/stop cycle count. An earlier version of this table filled those four cells from the nearline column beside them, which prints an unsourced number in a table whose other cells are published ones. Linear operating vibration in Gs is what the mission-critical datasheets do give, and that is a different measurement answering a different question: it is the chassis shaking the drive, not the drive’s neighbours shaking it. If those numbers exist anywhere they are in the 10E2400 and 15E900 SAS product manuals rather than the datasheets, and a figure quoted from a manual should say so.
Rotational vibration is the specification consumer drives will not print
A published rad/s squared figure is the cleanest single test of whether a drive was designed for a populated chassis. Both major vendors quote the same number for current nearline drives, and both attach a performance requirement to it. The Exos X24 SATA manual specifies random rotary operating vibration of 12.5 rad/s squared across 20 to 1500 Hz, and requires the drive to exhibit greater than 90 per cent throughput for sequential and random write operations under that power spectral density. Western Digital’s HC580 manual gives an overall RMS vibration level of 12.5 rad/s squared and names the feature Rotational Vibration Safeguard.
Note what the Seagate wording concedes: the drive is permitted to lose up to 10 per cent of its throughput at the rated level. Vibration tolerance is not a pass or fail property, it is a degradation budget.
Consumer NAS drives are the interesting middle case. Seagate IronWolf Pro and WD Red Pro datasheets describe rotational vibration sensors qualitatively and do not publish a rad/s squared figure at all, which means the two cannot be compared numerically with an Exos or an Ultrastar even though both have sensors. That is a real gap in the public record rather than an oversight this site can fill. The mechanism, and why eight bays is not four bays twice, is derived in drives for a NAS.
Load/unload and start/stop are two budgets twelve times apart
These get conflated constantly, and they are separate counters with separate ratings.
Load/unload is the head moving between the ramp at the outer edge of the platter and its flying position over the media. The Exos X24 specifies 600,000 cycles; the HC580 specifies a minimum of 600,000 normal load/unloads in a 40 degrees Celsius environment. Note “minimum” and note the temperature: it is a characterised floor at a stated condition, not a counter that trips.
Start/stop is the spindle stopping and starting. The HC580 manual specifies a minimum of 50,000 start/stop cycles at 40 degrees Celsius, and a minimum of 10,000 in extreme temperature or humidity within the operating range. Against 600,000 load/unloads that is a ratio of twelve to one, falling to sixty to one at the extremes of the envelope.
What triggers a load/unload is the drive’s own idle management. The Exos X24 power table lists Idle_A, Idle_B, Idle_C and Standby as distinct states; the transitions from Idle_A into Idle_B or Idle_C are the ones that unload the heads, and each one spends a cycle. The published power figures show why a drive is built to want them:
Exos X24 SATA, 24 TB, from the product manual's power table
average idle 6.22 W
Idle_A 6.25 W
Idle_B 3.89 W heads unloaded
Idle_C 2.91 W
Standby 1.09 W
Now cost the budget, which is my arithmetic on their rating:
600,000 cycles / (24 x 365) = 68.5 cycles per hour to exhaust the rating
in exactly one year
at 5 cycles/hour 600,000 / 43,800 per year = 13.7 years
at 30 cycles/hour 600,000 / 262,800 = 2.3 years
An aggressive idle timer is the only realistic way a home user destroys this budget, and it is the classic failure of consumer drives with a short parking timeout installed somewhere that touches them every few seconds. On a SATA pull the counter is SMART attribute 193, Load/Unload Cycle Count, which the Exos X24 manual lists among its supported attributes. Read it, divide by power-on hours, and compare against 68.5.
The start/stop budget is almost never the binding one. A machine powered up twice a day spends 730 cycles a year, so 50,000 lasts 68 years. A machine that spins its drives down after twenty minutes of idle and wakes them thirty times a day spends 10,950 a year and reaches the rating in 4.6 years, which is the only common way to get there.
There is also a power-off procedure that nobody follows. The HC580 manual specifies it: issue a STOP UNIT command (standby, standby immediate or sleep), explicitly not a flush cache, because flush cache does not invoke an unload; wait for command complete with a timeout of 60 seconds to allow for error recovery; then remove power. Cutting power to a spinning drive makes it park on its own reserve energy, which is an emergency unload rather than a normal one.
The error rate is a bound, and the 10K drives hold the better one
The table above used to stop at 10^15, and it should not have, because mission-critical drives are an order of magnitude better and that is the one specification where they still win. The Exos X24 nearline manual gives nonrecoverable read errors of 1 per 10^15 bits read, maximum. The Exos 10E2400 and Exos 15E900 datasheets both give 1 per 10^16.
10^14 bits = 12.5 TB consumer
10^15 bits = 125 TB nearline enterprise
10^16 bits = 1.25 PB 10K and 15K mission-critical
Cost a rebuild with it. A RAID 6 set of eight 20 TB drives losing one member reads the seven survivors in full:
7 x 20 TB = 140 TB = 1.12 x 10^15 bits
expected unrecoverable errors during the rebuild, worst case at the rated bound
at 1 per 10^14 11.2
at 1 per 10^15 1.12
at 1 per 10^16 0.112
probability of at least one, Poisson, mean 1.12
1 - exp(-1.12) = 67%
That 67 per cent is a worst-case bound and not a prediction. The rate is specified as a maximum, real drives measure considerably better, and no vendor publishes the true distribution, so the honest use of the number is to rank drives rather than to forecast an outcome. The longer treatment, including why the argument aged differently than its authors expected, is in drives for a NAS.
Underneath the specification is the error correction that produces it. The HC580 manual states 4608-bit LDPC, recovering a maximum 2,500-bit single burst error by on-the-fly correction and a maximum 3,500-bit single burst by offline correction. That is a different family of code from the Reed-Solomon most explanations still describe, and offline correction taking a second pass is what a long recovery timeout on an enterprise drive is spending its time on.
SAS is a different command set, and the connector rule is mechanical
SAS is not faster SATA. It is a different command set - SCSI rather than ATA - with different signalling, full duplex rather than half, dual ports, longer permitted cable runs and native support for expanders. A SAS drive needs a SAS controller, and there is no adapter.
| Link | Year | Raw rate | Encoding | Per lane | Four-lane wide port |
|---|---|---|---|---|---|
| SATA III | 2009 | 6 Gb/s | 8b/10b | 600 MB/s | - |
| SAS-1 | 2004 | 3 Gb/s | 8b/10b | 300 MB/s | 1,200 MB/s |
| SAS-2 | 2010 | 6 Gb/s | 8b/10b | 600 MB/s | 2,400 MB/s |
| SAS-3 | 2014 | 12 Gb/s | 8b/10b | 1,200 MB/s | 4,800 MB/s |
| SAS-4 | 2019 | 22.5 Gb/s | 128b/150b | 2,400 MB/s | 9,600 MB/s |
The encoding column is where the usable rate comes from, and SAS-4 changed character:
SAS-3 12.0 Gb/s x 8/10 = 9.60 Gb/s / 8 = 1,200 MB/s
SAS-4 22.5 Gb/s x 128/150 = 19.20 Gb/s / 8 = 2,400 MB/s
SAS-4’s frame is a 2-bit header, a 128-bit payload and 20 bits of Reed-Solomon forward error correction, which makes it the first SAS generation to carry FEC on the link at all. That is what buys 22.5 Gb/s over copper. SAS-5 is in development.
None of that limits one spinning drive. The Exos X24 SAS manual gives a sustained transfer rate of 272 down to 132 MiB/s, outer track to inner, so the inner track runs at 48.5 per cent of the outer - the roughly two-to-one ratio that comes from constant angular velocity and more sectors per track at a larger radius. The link generation matters when you aggregate.
The physical rule is the part people get wrong. A SATA drive’s connector is two separate segments - seven signal contacts and fifteen power contacts - with a gap between them. A SAS drive’s connector, SFF-8482, has the same footprint and 29 pins, but the gap is bridged: the plastic runs continuously between the segments, and the reverse of that tongue carries a second set of seven signal contacts, which is the drive’s second port. The same connector system implements single-port SATA and dual-port SAS, which is exactly why the compatibility is one-way.
- A SATA drive works in a SAS backplane or on a SAS cable. The receptacle is cut to accept the full bridged width, so the narrower SATA connector drops in and the second port’s contacts touch nothing. The controller talks to it over STP, the SATA tunnelling protocol.
- A SAS drive does not work in a SATA port. A SATA host receptacle carries a plastic key exactly where the SAS bridge sits, and the two collide. With the obstruction removed, a SATA controller speaks only ATA and could not issue a single SCSI command to the drive.
Cable length is a specification too, and a generous one. The Exos X24 SAS manual states that connecting the drive using high-quality cables is acceptable as long as the I/O cable length does not exceed 4 metres. The SAS specification permits up to 10 metres in general, against SATA’s 1 metre. Loose drives on a bench are a supported configuration on SAS in a way they are not on SATA.
Dual port means two addresses, and Linux will show you two drives
The Exos X24 SAS manual is explicit about what the second port is: the drive has two independent ports, which may be connected in the same or different SCSI domains; each drive port has a unique SAS address; and the two ports have independent port clocking, so one can run at 12 Gb/s while the other runs at 3 Gb/s. Command and task transfers can be concurrent on both, and the interface supports 1,200 MB/s per port or 2,400 MB/s across both.
In a server that is failover. In a homelab it is a trap. Connect both ports of
the same drive to one host - which a dual-expander JBOD will do to you without
being asked - and the kernel enumerates two SCSI devices for one piece of
hardware. Build a pool across what look like separate drives and the redundancy
is imaginary. The fix is device-mapper multipath, which collapses the paths into
a single /dev/mapper/mpathN and its /dev/dm-N alias; Red Hat’s documentation
is explicit that the devices in /dev/mapper are created early in boot and are
the ones to use. Check for duplicate serial numbers across /dev/sd* before
you create anything.
Spin-up on SAS is a protocol event, not a timer
Staggered spin-up on SATA is a backplane doing something to the power rails. On SAS it is in the protocol. The Exos X24 SAS manual: if the drive receives a NOTIFY (ENABLE SPINUP) primitive through either port, and has not received a START STOP UNIT command with the START bit equal to 0, it becomes ready for normal operations within 30 seconds. If a START STOP UNIT with START=1 and IMMED=1 is issued and no NOTIFY arrives within 5 seconds, the command fails. Stopping takes up to 23 seconds.
The practical consequence is that a SAS drive on a dumb cable to an HBA spins up when the HBA sends the primitive, and a drive that sits silent may be waiting for one rather than failing to start.
The HBA, IT mode, and the airflow the card assumes
IT mode - Initiator Target - means the card is a pass-through: every drive appears to the operating system as itself, with its own model, serial number, error counters and SMART data intact. IR mode is the same silicon with firmware that adds RAID, and Broadcom’s own documentation for the LSI SAS 9300-8i spells out what that means: the card can be upgraded to support Integrated RAID, being RAID 0, RAID 1, RAID 10 and RAID 1E. It writes metadata onto the drives and presents volumes. A hardware RAID card goes further: it owns the drives, caches writes in its own DRAM, hides sector-level errors by remapping behind your back, and ties the array’s on-disk format to that card family.
For ZFS, btrfs or mdadm this is not a preference. ZFS computes its own checksums, manages its own redundancy, needs its cache flushes honoured and needs honest error reporting to decide what to repair. A controller that second-guesses any of that is at worst the reason a scrub cannot find the problem.
Some RAID cards offer a JBOD or HBA mode that genuinely passes drives through.
Some offer a mode with that name which still interposes its cache and still eats
SMART. Verify rather than assume: attach a drive and check that
smartctl -a /dev/sdX returns the drive’s real identity and counters. If the
vendor string is the card, you are not passing through.
Cards shipped in IT firmware, or commonly reflashed to it, are built on a few Broadcom/LSI controllers - the 6 Gb/s SAS2008 and SAS2308, the 12 Gb/s SAS3008, and the later tri-mode parts. Their requirements are published, and the airflow line is the one that catches people:
| Card | Controller | Typical power | Airflow |
|---|---|---|---|
| SAS 9300-8i | SAS3008 | 13.0 W nominal, 19.04 W worst case | 200 LFM at 55 C inlet |
| SAS 9400-8i | SAS3408 | 10.05 W typical | 200 LFM at 55 C inlet |
| SAS 9400-16i | SAS3416 | 11.95 W typical | 200 LFM at 55 C inlet |
| SAS 9400-8e | SAS3408 | 9.48 W typical | 200 LFM at 55 C inlet |
| SAS 9400-16e | SAS3416 | 11.18 W typical | 200 LFM at 55 C inlet |
| SAS 9400-8i8e | SAS3416 | 12.39 W typical | 200 LFM at 55 C inlet |
Figures from the Broadcom LSI SAS 9300-8i user guide and the 9400 Series tri-mode HBA product brief. The controller column follows the port count and nothing else: eight ports is a SAS3408, sixteen is a SAS3416, and the 8i8e is a sixteen-port card with eight of them routed to external connectors. An earlier version of this table gave it as SAS3516, which is a MegaRAID RAID-on-chip part rather than anything in the 9400 HBA line - a wrong silicon name under a citation to Broadcom’s own brief, which is worse than an empty cell.
Two hundred linear feet per minute is a specification, not a suggestion, and it is roughly 1 metre per second of directed air across the heatsink. A passively cooled card in a quiet case with no fan pointed at it is outside its stated operating conditions, which is why these cards have a reputation for thermal shutdowns that has nothing to do with their age. The 9300-8i draws 1.59 A from the PCIe 12 V rail, addresses up to 1,024 SAS or SATA end devices, and gives 1,200 MB/s on a narrow port or 4,800 MB/s on a four-lane wide port. The 9400 generation draws less and adds NVMe, up to 24 devices.
Forward and reverse breakouts look identical and are not interchangeable
| Name | Where | Generation | What it is |
|---|---|---|---|
| SFF-8087 | Internal | 6 Gb/s | Mini-SAS 4i, four lanes |
| SFF-8088 | External | 6 Gb/s | Mini-SAS 4x |
| SFF-8643 | Internal | 12 Gb/s | Mini-SAS HD 4i, four lanes |
| SFF-8644 | External | 12 Gb/s | Mini-SAS HD 4x |
| SFF-8654 | Internal | 12/24 Gb/s | SlimSAS, 4i or 8i |
| SFF-8482 | Drive end | any | The 29-pin connector on a SAS drive |
| SFF-8680 | Drive bay | 12 Gb/s | SAS drive bay connector |
| SFF-8639 | Drive bay | any | U.2, six lanes, SAS or PCIe |
| SFF-TA-1001 | Drive bay | any | U.3, one bay accepting NVMe, SAS or SATA |
What you buy is a breakout, and forward and reverse breakouts are not interchangeable even though they look identical in a thumbnail. Forward runs from an HBA’s SFF-8087 or SFF-8643 to four drives; reverse runs from four motherboard SATA ports to an SFF-8087 backplane. Sellers list both as “SAS to SATA breakout cable” - read which end is the host. For loose SAS drives you want SFF-8643 to four SFF-8482, with a SATA power plug per drive on a separate tail.
U.2 and U.3 are worth knowing even on a spinning-disk budget, because they are where the used enterprise SSD market lives. SFF-8639 is a multifunction bay that carries SAS or PCIe on the same pins with an L-shaped key; SFF-TA-1001 rewires it so one backplane accepts NVMe, SAS or SATA. Drive interfaces has the full connector treatment.
Expanders, and sizing the uplink
An expander is a SAS switch, and unlike a SATA port multiplier it is a real crossbar: drives do not take turns, they contend for uplink bandwidth. The topology scales absurdly - the standard allows up to 65,535 devices through expanders, with an edge expander addressing up to 255 SAS addresses - so the limit you hit is bandwidth, not addressing.
Twenty-four nearline drives streaming at the Exos X24’s published 272 MiB/s outer rate want about 6,850 MB/s:
24 drives x 272 MiB/s = 6,528 MiB/s = 6,845 MB/s
one SFF-8643 uplink, 4 lanes at 12 Gb/s = 4 x 1,200 = 4,800 MB/s bottleneck
two SFF-8643 uplinks, 8 lanes = 8 x 1,200 = 9,600 MB/s not
Both sides of that comparison are in decimal megabytes, which is the only way it means anything: the drive figure is published in MiB/s and the link figure falls out of a bit rate, so carrying the binary number across into the decimal unit understates the demand by 5 per cent. An earlier version of this paragraph did exactly that, in an article that spends a section on why the two units differ.
Single-linked, that array is interface-limited during a scrub or a resilver - the two operations where you most want it to finish. In practice the drives will be reading their inner tracks at half the outer rate for much of the pass, so the real average sits below the bound, but a scrub is precisely the workload that runs every drive flat out at once. SATA drives behind an expander work, through STP, but that is where obscure interoperability problems have historically appeared. If you are mixing, buy one drive first.
Sector size, and the two completely different ways to change it
The difference is between physical sectors - the unit the media and its error correction are organised in - and logical sectors, the unit the drive lets the host address.
| Format | Physical | Logical | Behaviour |
|---|---|---|---|
| 512n | 512 | 512 | Native. Old drives, and many 10K/15K SAS drives |
| 512e | 4096 | 512 | Emulated. The drive does read-modify-write internally |
| 4Kn | 4096 | 4096 | Native 4K. The host must speak 4K |
On a 512e drive, a write that does not cover a whole physical sector costs a
full rotation. The drive reads the 4,096-byte sector, merges the new data,
recomputes the error correction, and waits for the platter to come round:
8.33 ms at 7,200 rpm (60 / 7,200), 6.00 ms at 10,000, 4.00 ms at 15,000.
The physical sector is 4,096 bytes on the whole current nearline range regardless of the logical setting - the Exos X24 manual lists 4096 bytes per physical sector for the 24, 20, 16, 12 and 10 TB models alike. A 512e drive is a 4K drive wearing a translation layer.
Eight logical sectors fit in one physical sector, so alignment is a question of
whether the partition starts on a multiple of eight. 63 mod 8 = 7, so a
partition at LBA 63 - the old MS-DOS convention - makes every 4 KiB filesystem
block span two physical sectors and every write two read-modify-writes.
2048 mod 8 = 0, so the modern 1 MiB default is aligned. Check before committing
a pool:
smartctl -i /dev/sda | grep -i sector
# Sector Sizes: 512 bytes logical, 4096 bytes physical
sg_readcap -l /dev/sda
# Logical block length=512 bytes
# Logical blocks per physical block exponent=3
An exponent of 3 means 2^3 = 8 logical blocks per physical: 512 logical over
4,096 physical, so the drive is 512e. Exponent 0 with a block length of 512 is
512n; exponent 0 with 4,096 is 4Kn. lsblk -o NAME,PHY-SEC,LOG-SEC,MODEL gives
the same answer for every drive at once. On SATA the same fact lives in IDENTIFY
DEVICE word 106, which the Exos X24 manual documents as 6003h on a 512e drive and
5000h on a 4Kn one. Word 106 is a single 16-bit word, so the way to read it is in
binary:
6003h = 0110 0000 0000 0011
bit 15 clear, bit 14 set the word carries valid information
bit 13 set multiple logical sectors per physical sector
bit 12 clear logical sector is 256 words, i.e. 512 bytes
bits 3:0 = 3 2^3 = 8 logical sectors per physical 512e
5000h = 0101 0000 0000 0000
bit 15 clear, bit 14 set the word carries valid information
bit 13 clear one logical sector per physical sector
bit 12 set logical sector longer than 256 words
bits 3:0 = 0 2^0 = 1 logical sector per physical 4Kn
The Linux kernel reads it the same way: it tests the top three bits for 6000h before trusting the word, then takes the exponent from the low four bits. An earlier version of this article put those two fields at bit 62 and bits 19:16, which cannot be right in a 16-bit word and does not reproduce either of the hex values printed beside it. Those bit numbers are real, but they belong to a different structure in the same manual: the IDENTIFY DEVICE data log, log address 30h, page 02h, states the physical and logical sector size as a qword, and there the same pair of fields does sit at bit 62 and bits 19:16. Word 106 and that qword carry the same fact at different widths, which is exactly how the two numbering schemes get swapped.
Fast format takes seconds; FORMAT UNIT takes hours
This distinction is missing from most write-ups and it decides whether converting a drive is a coffee break or a weekend.
Changing only the logical sector size between 512 and 4096 is a fast format.
On SATA the Exos X24 manual names the command: SET SECTOR CONFIGURATION EXT
(B2h), from the ACS-4 standard, which quickly converts between 512 and 4096 byte
logical sector formats, with the change taking effect immediately on command
completion. The default shipping format is 512e. On SAS the equivalent is T10
Fast Format, requested by setting the FFMT bits in byte 4, bits 1:0 of the FORMAT
UNIT command to 01b - Seagate documents the CDB as 04 14 00 00 01 00.
Western Digital adds a detail worth having on a listing page: changing the block size does not change the model number the drive reports. A 4Kn drive and a 512e drive can be the same part number, so a listing’s model number does not tell you which state it is in, and neither does the seller.
Changing the protection format, or converting off a 520-byte logical block, is a full FORMAT UNIT which rewrites every sector’s error correction across the whole platter. That is the hours-to-days case, and it has its own section below.
ashift, and the two mistakes it causes
One consequence for ZFS is expensive and permanent. A vdev’s ashift is fixed
at creation and cannot be changed, so a pool built at ashift=9 on 512e drives
does read-modify-writes for every small write and every metadata update, for its
whole life. Create with -o ashift=12.
The second mistake is newer and specific to reformatted enterprise SSDs. Drives
converted from a 520-byte logical block to 512 have been reported afterwards
declaring an 8,192-byte physical block, at which point ZFS warns that the
block size is configured at 4096 and native at 8192, and the correct value is
ashift=13 rather than the usual 12. Check smartctl -i output after any
reformat rather than assuming the answer you had before it.
Some drives also misreport, claiming 512/512 on media that is physically 4K, which is why ZFS carries per-drive quirk lists at all. And legacy BIOS boot assumes 512-byte sectors, so a 4Kn drive is a data drive on such a machine and not a boot drive.
Zoned drives are a separate device class
Some drives sold out of datacentres are host-managed shingled drives, and the standards call them a different device model rather than a variant. Under the SCSI Zoned Block Commands and Zoned ATA Commands specifications, a host-managed device accommodates only sequential write workloads: a write must start at a sector aligned with the zone’s write pointer, and any out-of-order write forces the device to abort the operation and flag an error, leaving recovery to the host. A host-aware device offers backwards compatibility and will accept random writes anywhere, absorbing the cost internally.
No model number tells you this reliably, and this site will not guess it from
one. The drive will tell you: cat /sys/block/sda/queue/zoned returns none,
host-aware or host-managed, and only the first is a conventional drive. See
CMR vs SMR, and check the stated recording method in
the hard drive listings if a rebuild is in your future.
T10 protection information is not the 520-byte sector problem
This article used to run those two together, and they are different things with different symptoms, different diagnostics and different fixes. Getting them confused is why people reformat drives that never needed it.
What protection information is
SCSI defines an optional protection information field in which eight bytes are appended per protection interval:
| Bytes | Field | What it catches |
|---|---|---|
| 2 | Logical block guard | A CRC over the data bytes: corruption in flight or on media |
| 2 | Logical block application tag | Defined by the application, commonly unused |
| 4 | Logical block reference tag | Normally derived from the LBA: a misdirected write |
The reference tag is the clever half. A checksum tells you the data is wrong; a reference tag tells you that perfectly valid data was written to or read from the wrong address, which is the failure mode array vendors lose sleep over.
The interval count depends on the block size. The sg_format manual page
describes it precisely: devices with a 512-byte logical block typically have one
protection interval appended, making the logical block data 520 bytes long, while
devices with a 4096-byte logical block often carry eight protection intervals for
a total of 4,160 bytes.
Here is the part that matters for a buyer. Seagate’s Exos X24 SAS manual states that PI-formatted drives are physically formatted to 520-byte sectors that store 512 bytes of customer data with 8 bytes of protection information appended. The drive still reports a 512-byte logical block to the host. It sets PROT_EN in READ CAPACITY(16). It enumerates normally on an ordinary HBA, produces no kernel error, and works. What you see is this:
sg_readcap --long /dev/sdb
# Logical block length=512 bytes
# Protection: prot_en=1, p_type=1, p_i_exponent=0 [type 2 protection]
p_type is offset by one from the type number, which is the detail that
makes this output easy to misread: in READ CAPACITY(16) a 0 means type 1, a 1
means type 2 and a 2 means type 3. An Exos X24 shows 1, because the next
subsection is the same manual saying it implements type 2 and does not implement
type 1. A PI drive from a vendor that does implement type 1 shows 0 instead, and
an earlier version of this article printed that line under an Exos heading, which
contradicted the table immediately below it. The diagnostic point is unchanged
either way: prot_en=1 on a 512-byte logical block is a working PI
drive rather than a broken one.
A standard INQUIRY has a PROTECT bit, and VPD page 0x86 lists which protection types the drive supports.
There are four PI types and your drive probably supports two
Most explanations describe Type 1, which is the one current Seagate nearline SAS drives do not implement. From the Exos X24 SAS manual:
| Type | Exos X24 SAS | What it does |
|---|---|---|
| Type 0 | supported | No protection information bytes on the drive |
| Type 1 | not supported | Reference tag is the low 32 bits of the LBA |
| Type 2 | supported | Checking control and expected fields in 32-byte CDBs |
| Type 3 | not supported | Guard tag only |
Type 2 exists because Type 1’s implicit LBA-derived reference tag cannot express a transfer that is not addressed the way the tag assumes; it uses 32-byte command descriptor blocks to seed the expected tag explicitly.
The type is a formatting property, not a setting. Seagate is blunt about it: once a drive is formatted to a PI type it may be queried with READ CAPACITY(16), and it can be changed at any time to a new type but requires a low-level format which destroys all existing data on the drive. No other vehicle for changing the PI type is provided by the T10 SBC-3 specification.
What PI costs
Two separate costs, and they are often collapsed into one.
The transfer cost is published. Seagate states that sequential performance of a
PI drive is reduced by approximately 1.56 per cent, because the extra protection
bytes are transferred from the media and are not counted as part of the data
delivered to the host. That figure is exactly 8 / 512 = 1.5625%.
The capacity cost is separate, and Seagate publishes enough to compute it rather than estimate it. The Exos X24 SAS manual’s formatted capacity table gives the LBA count at each format, with LBA counts above 8 TB calculated per the SFF-8447 standard:
Exos X24, 24 TB, logical block addresses as published
512 B without PI 46,875,541,504 LBAs x 512 = 24,000,277,250,048 B = 24.000 TB
520 B without PI 45,923,434,496 LBAs x 520 = 23,880,185,937,920 B = 23.880 TB
512 B with PI 45,923,434,496 LBAs x 512 = 23,512,798,461,952 B = 23.513 TB
difference in addressable blocks
46,875,541,504 - 45,923,434,496 = 952,107,008 LBAs
952,107,008 / 45,923,434,496 = 2.07% more blocks after reformatting to 512
Note the third line. A PI-formatted drive presents 23.513 TB where an unprotected one presents 24.000 TB, on the same media, because the eight bytes per block are real media that is not yours. And note the second line against the first: 45,923,434,496 blocks of 520 bytes is 23.880 TB, not 24.000 TB, so the 520-byte format also loses about half a per cent of the media to format efficiency before the protection bytes are counted at all. Both observations are arithmetic on Seagate’s published table.
The same manual gives the 16 TB figures: 31,251,759,104 LBAs at 512 bytes against 30,616,322,048 at 520, a ratio of 1.0208, which is the same 2.1 per cent.
The simple model people quote is close enough and worth having when you have no table. On media holding 4,000,000,000,000 bytes of formatted sectors:
4,000,000,000,000 / 520 = 7,692,307,692 sectors
7,692,307,692 x 512 = 3,938,461,538,304 B = 3.938 TB against 4.000 TB
3.938 / 4.000 = 0.98462, i.e. 1.538% less user data
An odd capacity in a listing, 1.97 TB where you expected 2 TB, is usually a 520-byte drive somebody enumerated without reformatting. The site’s own capacity guide covers the other reasons a number comes out wrong.
The 520-byte logical block is the thing that looks like a dead drive
A drive with a 520-byte logical block is a different animal from a PI-formatted drive. It is an array vendor’s convention, not T10 protection information, and the host cannot address it at all. NetApp’s scheme is a block checksum scheme, in which the last 8 bytes of each 520-byte sector hold a WAFL block checksum, eight sectors to a 4 KB WAFL block; for 512-byte SATA drives NetApp instead uses a nine-sectors-per-4 KB arrangement, eight of data and one of checksum. EMC arrays use their own.
The Linux sd driver refuses it, and the symptom is unambiguous:
sd 6:0:0:0: [sdb] Unsupported sector size 520.
sd 6:0:0:0: [sdb] 0 512-byte logical blocks: (0 B/0 B)
sg_readcap -l /dev/sdb confirms it with Logical block length=520 bytes rather
than the prot_en=1 line a PI drive shows. That is the diagnostic difference.
A PI drive says 512 and works; a 520-byte-block drive says 520 and does not.
Which sizes appear is less predictable than the folklore claims. 520 is by far the most common, and both SanDisk and Seagate parts turn up with it. 528 appears on some Seagate Constellation drives, and 4104 and 4160 are the 4K-native equivalents. The widely repeated mapping of NetApp and EMC to 520 and IBM to 524 or 528 is not reliable: it varies by array generation and by what the last owner did, and a seller reading a sticker knows no more than you do. Read the drive.
Nothing about Seagate’s supported list encourages guessing either. The Exos X24 SAS manual enumerates the logical block sizes it will accept: 512 and 520 on a 512E model, 4096 and 4160 on a 4K-native model. 524 and 528 are not on that list. A drive presenting one of those is not a current Seagate nearline part in an unusual state, it is something else.
Reformatting a 520-byte drive, and the ways it goes wrong
There is no hdparm route and ATA secure-erase commands do not apply. The tool
is sg_format from sg3-utils, issuing a SCSI FORMAT UNIT.
sg_format /dev/sdb # report only, no changes
sg_format --format --size=512 --fmtpinfo=0 /dev/sdb # do it
sg_requests --progress /dev/sdb # "Progress indication: 23.45% done"
echo 1 > /sys/block/sdb/device/rescan # after success, tell Linux
--fmtpinfo is the field that decides the protection format, and its encoding is
not obvious, because the two-bit value does not number the protection types. The
manual page’s table runs the other way round, from the type you want to the
options that select it:
| Protection type | Options |
|---|---|
| Type 0, no protection information | --fmtpinfo=0 |
| Type 1 | --fmtpinfo=2 --pfu=0, which is what the older --pinfo sets |
| Type 2 | --fmtpinfo=3 --pfu=0 |
| Type 3 | --fmtpinfo=3 --pfu=1 |
The value 1 selects nothing at all. FMTPINFO=01b is not a defined
combination in SBC-3, and a drive given it rejects the command. An earlier
version of this article read that table as a value-to-type mapping and reported
1 as type 1, which would have failed on the first drive anybody tried it on. So
--fmtpinfo=0 is what strips protection information, and changing the size alone
is not enough. The related --pie option, the protection interval exponent, can
only be non-zero with types 2 and 3.
Two other options are worth knowing before you need them. --resize changes the
number of blocks the drive reports without touching data, which is a
different and much faster operation than a format. --count=-1 sets the
manufacturer’s maximum block count, which is how you undo a resize.
Four honest warnings.
It is slow, and the manual page’s defaults tell you how slow. Without the
IMMED bit, sg_format uses a default command timeout of 72,000 seconds, which is
20 hours, rising to 144,000 and 288,000 seconds for larger disks. The manual page
says plainly that with hard disks over 10 TB in size that can be days. Real
reports put a conversion anywhere from 10 minutes on a small SSD to 10 hours on a
large spinning drive.
A failure can leave the drive worse than it started. From the same manual page: if the MODE SELECT command succeeds and the FORMAT fails, the disk may be in a state that the standard calls “format corrupt”. The recovery is another format. If you want to know which state a drive is in, the Exos X24 SAS manual lists Log Sense page 08h, Format Status, among its supported log pages, and that page is the thing to read rather than guessing from a failed command.
It does not always work first time. The documented escalation, from people
who do this in volume, runs: add --six for NetApp drives and older Seagate
Constellation ES2 parts, which need the six-byte MODE SELECT; repeat the force
flag to push FORMAT UNIT past mode-sense validation; and for the stubborn cases,
zero the drive at its original size first and then immediately reformat to 512
before anything writes to it.
sg_format -v --format --size=512 --six /dev/sg2 # NetApp, Constellation ES2
sg_format -F -F -F --size=512 /dev/sgX # force past mode-sense
sg_format --format --size=520 /dev/sgX # zero at the original size,
sg_format --format --size=512 /dev/sgX # then convert immediately
LSI SAS2308 and Dell H200 and H200e controllers are the ones most often reported as working for this.
You are discarding real protection, which is only fine because ZFS and btrfs do the equivalent in software and your HBA was never going to use the T10 fields anyway.
The Exos X24 SAS manual also lists which FORMAT UNIT bits it honours - IMMED, STPF, DCRT, DSP and IP - and notes that SI, security initialize, is not supported. If a script you found online passes SI, it will fail on these drives.
SANITIZE is usually the better command than FORMAT UNIT
If the goal is to erase a used drive rather than to change its block size, FORMAT
UNIT is the wrong tool and has been since SBC-3 revision 27 introduced SANITIZE.
sg_sanitize offers three service actions:
| Service action | What it does | Duration |
|---|---|---|
--crypto |
Overwrites the drive’s internal cryptographic key | Seconds |
--block |
Block erase of the media | Comparable to a format |
--overwrite |
Pattern overwrite, --count=1 to 31 passes, --invert between them |
Longest |
--overwrite needs --pattern or --zero to say what to write. --ause sets
the allow-unrestricted-sanitize-exit bit, and --fail is how you clean up after
a sanitize that failed while AUSE was set.
One warning from the manual page deserves to be quoted in full rather than paraphrased, because the second half of the sentence is the half that gets dropped: if a sanitize operation is interrupted, for example by a power cycle, then after power up any remaining user data will not be available and the sanitize operation will continue. The operation picks itself up after power on. What does not come back is the data, which is the opposite of a failed format that you can simply run again. Start it on a machine that is not going to be unplugged, and treat an interruption as having finished the job rather than having abandoned it.
This is the operation vendors mean when they claim compliance with a standard. The Exos 15E900 datasheet says Seagate Secure models meet the NIST 800-88 media sanitization specification and support the Trusted Computing Group standard, and the Exos 10E2400 datasheet’s own footnote adds ISO/IEC 27040 alongside NIST 800-88, with the caveat that it may require a TCG-compliant host or controller. NIST SP 800-88 Revision 1 defines three levels - Clear, Purge and Destroy - and IEEE 2883-2022 is its current companion, naming Overwrite, Block Erase and Cryptographic Erase as acceptable purge techniques. A cryptographic erase on a self-encrypting drive is a purge under that framework, in seconds, which is why datacentres use it and why the drive you buy has usually had it done.
Self-encrypting drives, and telling a locked drive from a dead one
This is the failure that costs people the most money on the used market, because the drive looks broken and the cause is invisible.
The encryption was always on
The Exos X24 SATA manual states it plainly: there is one inline encryption engine for each port, using AES-256 data encryption keys in XTS mode, and the encryption engines are always in operation and cannot be disabled. A non-encrypting model and an SED model are the same hardware; the manual puts the difference at about 30 mA more on the 5 V supply, roughly 150 mW, with the security portion of the controller ASIC enabled. The drive supports up to 16 data bands, each with its own key and its own BandMasterX password.
So a “non-SED” nearline drive is still encrypting everything it writes. What the SED feature adds is the ability to lock a band and refuse access without a credential.
The mechanism that produces a locked pull is in the specification
The manual describes the exact scenario that puts a locked drive on eBay: the variable LockOnReset should be set to PowerCycle to ensure that the data bands are locked if power is lost, and this scenario occurs if the drive is removed from its cabinet. The drive will not honour any data read or write requests until the bands have been unlocked.
Read that again with a seller’s workflow in mind. An array operator who does not run a cryptographic erase before decommissioning, and who simply pulls the drives, produces locked drives by design. The drive was configured to do this.
How to tell a locked drive from a dead one. A locked drive enumerates. It reports its model, serial number and capacity. It answers INQUIRY and IDENTIFY, it returns SMART data, and its self-test may pass. What it will not do is return user data: reads fail with a sense key rather than with silence. A dead drive usually fails earlier and harder - no identity, no capacity, or a capacity of zero. If a drive gives you a full identity and refuses every read, suspect locking before you suspect heads.
Reverting it, and the case where you cannot
The escape hatch in the specification is PSID revert. The Exos X24 manual: in order to execute the RevertSP method the unique PSID, Physical Secure ID, printed on the drive label must be provided, and PSID is not electronically accessible and can only be manually read from the drive label or scanned in via the 2D barcode. It is 32 characters, entered in capitals without dashes. RevertSP returns every security provider to factory state and destroys the data by design, which is the point.
For a TCG Opal drive, the open-source tool is sedutil:
sedutil-cli --scan # finds Opal-compliant drives
sedutil-cli --query /dev/sdX # Locked = Y, LockingEnabled = Y
sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID <PSID> /dev/sdX
# success prints: INFO: revertTper completed successfully
# a wrong PSID returns NOT_AUTHORIZED; add -vvvvv for diagnostics
And here is the part that is usually left out. sedutil is an Opal tool, and the class most SAS enterprise pulls belong to is TCG Enterprise SSC, which it does not handle. A well-documented case on the TrueNAS forums involved an HGST SS200 SAS SSD whose query reported Locked = Y, LockingEnabled = Y, MediaEncrypt = Y and isEprise = 1. With both the MSID and the PSID in hand, sedutil-cli returned “Command failed on send 255” and “Command failed on exec 255”, and the drive entered a frozen state during session establishment. The PSID revert failed. Power-cycling for more than ten seconds did not help. The thread was never resolved, and a later poster with 72 of the same drives reported no working solution.
Treat that as the realistic downside case. A locked TCG Enterprise drive may be recoverable with the array vendor’s own tooling, and may not be recoverable by you at all.
There is also a reported case that goes one step further: Dell EMC OEM Seagate Exos X16 drives on VV08 firmware are said to hide the TCG interface entirely, so standard SED tools report the configuration as unknown or unsupported and the drive cannot even be identified as an SED. I have not been able to verify that from a primary source, so treat it as a report rather than a fact - but it is the right shape for the class of problem, and it is a reason to prefer a listing that shows the label.
A listing photograph showing the label beats one showing the lid. The PSID, the firmware revision, the model number and the world wide name are all on it.
Verifying an erase will confuse you
One last trap, from the Exos X24 SATA manual’s description of ATA SECURITY ERASE UNIT on an SED. A normal erase changes the media encryption key for the drive and then overwrites by repeatedly writing a single sector of random data across the whole drive, with the write bypassing the media encryption. On reading back the overwritten sectors, the host receives a decrypted version, using the new encryption key, of the random data sector, so the returned data will not match what was written.
If you erase a drive and then read it expecting to find your pattern, you will find noise, and the drive is working correctly. Verification has to be done against what the drive says it did, not against a byte comparison.
Reading the history off a SAS pull is harder than off a SATA one
SAS drives do not have the numbered SMART attribute table people expect.
Attribute 5 Reallocated_Sector_Ct, 9 Power_On_Hours, 194 Temperature_Celsius, 197
Current_Pending_Sector and 198 Offline_Uncorrectable are ATA attributes. A
SCSI drive reports the same facts through log pages, and smartmontools documents
the consequence: for SCSI devices the attributes come from the temperature and
start-stop cycle counter log pages, in a relatively free format compared with ATA
attributes. smartctl -a prints them in a completely different shape:
SMART Health Status: OK
Current Drive Temperature: 31 C
Drive Trip Temperature: 60 C
Accumulated power on time, hours:minutes 43970:12
Elements in grown defect list: 0
Non-medium error count: 0
Error counter log:
Errors Corrected Total errors Gigabytes Total
fast | delayed corrected processed uncorrected
read: 183457921 0 183457921 98765.432 0
write: 0 0 0 12345.678 0
Elements in grown defect list is the SAS equivalent of attribute 5: sectors
reallocated since the drive left the factory, and the number that matters most.
Anything but zero on a drive you have just bought is a conversation with the
seller. Total uncorrected should be zero on both rows. A fast-corrected count in
the hundreds of millions is normal - drives correct constantly by design, and the
column that means something is the uncorrected one. Gigabytes processed is what
feeds the workload-rate arithmetic earlier in this article.
The log pages worth asking for by name
For SCSI devices smartctl -a is equivalent to a longer list of log pages, and
knowing the individual flags lets you ask for the one you want:
| Flag | What it prints |
|---|---|
-l defects |
LBAs the background scan could not read |
-l background |
Background media scan results, after power up and periodically |
-l sasphy |
SAS protocol-specific log page 0x18, with PHY event counters |
-l ssd |
Solid state media percentage used endurance indicator, 0 new to 100 spent |
-l envrep |
Environmental reporting: temperatures and relative humidity |
-l genstats |
General statistics |
-l farm |
Seagate Field Access Reliability Metrics, smartctl 7.4 and later |
-l sasphy is the one nobody runs and everybody needs. PHY event counters
are the cable and connector diagnostic: invalid dword counts, disparity errors
and loss-of-sync counts rising over a few hours of load mean a bad cable, a dirty
connector or a marginal expander, and they look exactly like a bad drive if you
only read the health status.
-l farm is newer and useful for provenance, because Seagate’s FARM log is a
separate store from standard SMART with its own reliability metrics. Two caveats
from the manual page: it is marked as a new experimental feature in smartctl 7.4,
and some Seagate drives do not support it. The ATA and SAS FARM formats differ
slightly. Seagate’s own openSeaChest suite is the vendor-side equivalent, and
cross-checking FARM against SMART is the practical answer to a tampered attribute
table - a claim that circulates about used drives and is credible enough to check
rather than dismiss.
The structural gap in SCSI health data
smartmontools names it directly: one shortcoming of the informational exception data provided by SCSI devices is that no LOG SENSE page tells the user how many hours the device has been in use for. Accumulated power-on time surfaces through the background scan results page rather than through a dedicated counter, which is why it appears in a different place in the output from everything else, and why some drives and some tools will not show it at all.
The Exos X24 SAS manual enumerates which pages the drive supports, and the absences are the informative part. It supports Background Scan Results (15h), Format Status (08h), Information Exceptions (2Fh), Non-medium Error (06h), Protocol Specific Port (18h), the read, write and verify error counters (03h, 02h, 05h), Self-test Results (10h), Start-stop Cycle Counter (0Eh), Temperature (0Dh), Power Condition Transition (1Ah), Cache Statistics (37h) and the Factory Log (3Eh). It does not support Last n Error Events (07h), Last n Deferred Errors (0Bh) or Buffer Over-run/Under-run (01h).
That last group is why a SAS drive’s history is thinner than a SATA drive’s: the drive keeps counters, not a log of what happened and when.
On the SATA side
The attribute table applies as usual, plus three that matter on enterprise pulls.
Attribute 193, Load/Unload Cycle Count, against the 600,000 rating, as derived earlier. Attribute 194, Temperature_Celsius, against the envelope the reliability figure assumes. And attribute 22, Current Helium Level, on sealed helium drives: it is a pre-fail attribute with a normalised failure threshold of 25, tripping when the internal environment goes out of specification. Backblaze first observed it on HGST Ultrastar He8 drives in 2015.
Helium failure is abrupt rather than gradual because the drive is a sealed system that manages its own atmosphere. The HC580 manual states that helium is constantly circulated and filtered when the drive is operational, with no venting of the head-disk assembly. A drive losing its seal is not a drive slowly getting worse.
Backblaze’s published analysis puts most of the predictive signal in five attributes: 5 Reallocated Sector Count, 187 Reported Uncorrectable Errors, 188 Command Timeout, 197 Current Pending Sector Count and 198 Offline Uncorrectable. They schedule a drive for replacement once attribute 187 rises above zero. The honest figure alongside that: they reported in 2016 that in 76.7 per cent of drive failures, one or more of those five had a raw value greater than zero - which means roughly a quarter of failures gave no SMART warning at all.
Run smartctl -t long /dev/sdX inside the return window either way. The
used-drive guide covers what to do when the
result is bad, and how to prove a capacity claim before the clock runs out.
A fleet failure rate tells you almost nothing about one drive
Backblaze’s Drive Stats is the only large public dataset, and it is far more specific than the “low single digits” this article used to say. From their Q1 2026 report: a quarterly annualised failure rate of 1.24 per cent and a lifetime rate of 1.39 per cent, across 341,263 drives and 30,203,180 drive days in the quarter, with 1,030 failures. Their full-year 2025 report gives an annual rate of 1.36 per cent, down from 1.55 per cent in 2024, with 349,462 drives at year end. Of the 10,220 drives they deployed in the quarter, 9,404 were above 20 TB - more than 90 per cent of new deployments - and that pool ran at 0.85 per cent, which the report qualifies in the same breath by noting the drives are still young. An earlier version of this article attached the 0.85 figure to a cohort of more than 86,000 units, which inflates the sample about ninefold and drops the caveat the source attaches to it.
The bathtub claim in the old version of this article was wrong
This guide previously said that the distribution is a bathtub and a five-year pull is past the flat part. Backblaze’s own 2025 revisit of the bathtub curve contradicts that. Their observed shape is a fairly even failure rate through the significant majority of the drives’ lives, then a steep spike once drives reach failure territory. The numbers: 1.30 per cent AFR in the first year, and a peak of 4.25 per cent at ten years and three months. That peak is about a third of what they saw in earlier analyses - 13.73 per cent in 2013 and 14.24 per cent in 2021 - and they describe the average longevity before the spike as having risen by about two years between those two datasets.
On that evidence a five-year pull is inside the flat part, not past it. The correction matters because the old claim is the single most common argument against buying pulls at all, and the best available public data does not support it.
Why it still tells you nothing about the drive in the listing
Three reasons, in order of size.
Model spread swamps the average. In the Q1 2026 data, individual models ranged from 0 per cent to several per cent within the same capacity: 12 TB models between 0.38 and 4.59 per cent, 14 TB between 0.33 and 4.9 per cent, 16 TB between 0 and 3.61 per cent. The worst performer in Q4 2025 was an 8 TB HGST at 10.29 per cent. Both ends of that 12 TB spread are Seagate models, which is the clearest available statement that the badge on the drive is not the variable. A fleet number averages a population you are not buying from.
Conditions do not transfer. Backblaze’s drives live in a purpose-built chassis with directed airflow, at a workload and a temperature the vendor characterised. Yours will not.
The sample size is one. This is the point both vendors make in their own manuals, and it is worth converting into arithmetic you can use. For a set of drives, assuming independence and a constant hazard - both of which are approximations, and the second is the one the bathtub data questions:
P(at least one failure) = 1 - (1 - AFR)^(drives x years)
eight drives, five years
at the Exos X24 specified AFR of 0.35% 1 - 0.9965^40 = 13.1%
at Backblaze's lifetime 1.39% 1 - 0.9861^40 = 42.9%
Those two numbers are for the same eight drives, and the gap between them is the gap between a specification measured in a cold aisle and a fleet measured in the field. Neither is a prediction for your shelf. Both are reasons to buy into redundancy rather than into a single drive, which is the only conclusion this data actually supports.
Power, heat and noise, in numbers the datasheets publish
Power, measured rather than asserted
The Exos X24 SATA product manual’s power tables give the following for the 24 TB and 20 TB models, with the 16 TB at 5.57 W average idle and the 12 and 10 TB at 5.4 W:
| State | Exos X24 SATA 24 TB | Exos X24 SAS 24 TB | Ultrastar DC HC580 24 TB |
|---|---|---|---|
| Average idle | 6.22 W | 6.84 W | - |
| Idle_A | 6.25 W | - | 5.5 W |
| Idle_B | 3.89 W | 4.41 W | 3.7 W |
| Idle_C | 2.91 W | 3.31 W | 3.2 W |
| Standby | 1.09 W | 1.4 W | 1.2 W |
| Sequential write 64K QD16 | 8.53 W | - | 7.6 W read/write |
| Random read 4K QD16 | 8.88 W | - | 9.4 W at QD8 |
Two observations a listing will not make for you. The SAS version of the same drive draws about 0.6 W more at idle, which is the second port’s electronics. And the spread between idle and full random load is under 3 W, so a nearline drive is close to a constant load and sizing a supply on idle figures is nearly right.
Converting to the number that actually decides a build:
per-terabyte idle energy, from the manufacturers' own figures
Exos X24 24 TB 6.22 W x 8,760 h = 54.5 kWh/year / 24.0 TB = 2.27 kWh/TB/year
Exos 10E2400 2.4 TB 4.90 W x 8,760 h = 42.9 kWh/year / 2.4 TB = 17.89 kWh/TB/year
Exos 15E900 900 GB 5.70 W x 8,760 h = 49.9 kWh/year / 0.9 TB = 55.48 kWh/TB/year
Multiply by your own tariff and the years you plan to run them. The per-drive figures are the vendors’; the division is mine.
Fewer, larger drives is almost always the right shape for a home array, and the gap also buys fewer ports, bays and things that can fail.
Spin-up is the number that sizes the power supply
The Exos X24 SATA manual gives a maximum start current of 2.035 A DC peak and 2.36 A AC peak on the 12 V rail, with delayed motor start at a maximum of 0.812 A, and a lower startup current available as an optional configuration through Smart Command Transport. The SAS version is 2.061 A peak DC. Size from the AC peak, which is the larger of the two published maxima.
twelve drives starting together, at the published AC peak
12 x 2.36 A = 28.3 A on the 12 V rail = 340 W
the same twelve with delayed motor start
12 x 0.812 A = 9.7 A = 117 W
An earlier version of this section also quoted a typical startup current of 2.6 A and sized the supply from that instead, giving 31.2 A and 374 W. A typical figure cannot be larger than a maximum on the same page, so either one of the two was mislabelled or they are different measurements the article did not distinguish, and guessing which would be inventing a specification. Sizing from the published maximum is the conservative reading and it is the one used here. Leave the margin in the supply rather than in the arithmetic.
That is the whole argument for staggered spin-up, and on SAS it is the NOTIFY primitive described earlier rather than anything you configure. If your backplane or HBA does not stagger, the supply has to cover the peak, and a supply that sags during spin-up produces a fault that looks like several bad drives at once.
Heat, and the measurement procedure nobody follows
The Exos X24 specifies an operating range of 10 to 60 degrees Celsius drive-reported, with a maximum allowable drive-reported temperature of 60. The manual then says the part that matters: air flow may be required to achieve consistent nominal drive temperature values, and gives the procedure - place the drive in its final mechanical configuration, perform random write and read operations, let the temperatures stabilise, then monitor the current drive temperature using SMART attribute 194 or Device Statistics log 04h page 5. Western Digital puts the responsibility in one sentence: the system is responsible for maintaining a drive sensor temperature below 60 degrees Celsius.
The reliability envelope earlier in this article wanted 30 degrees or below. The operating range goes to 60. Those are different numbers answering different questions, and quoting the second while implying the first is the most common way a datasheet is misread.
Acoustics are sound power in bels, which is not what you will hear
This is the specification most often misquoted, because the unit is unfamiliar and people read it as if it were a dBA figure at the ear. It is not.
Published acoustic figures are sound power levels, in bels referenced to one picowatt, measured per ISO 7779. Sound power is a property of the source and does not depend on where you stand. Sound pressure, which is what you hear, does.
| Drive | Idle | Seek or operating |
|---|---|---|
| Exos X24 SATA | 2.8 bels typical, 3.0 max | 3.2 bels typical, 3.4 max |
| Exos X24 SAS | 2.8 bels typical | 3.0 bels typical |
| Ultrastar DC HC580 | 2.0 bels typical, 2.5 max | 3.2 bels typical, 3.4 max |
Converting to something you can compare with a room, in a hemispherical free field at one metre:
Lp = Lw - 10 x log10(2 x pi x r^2)
= Lw - 8 dB at r = 1 m
2.8 bels = 28 dB sound power -> about 20 dBA at one metre
3.2 bels = 32 dB sound power -> about 24 dBA at one metre
eight drives seeking, incoherent sources
+10 x log10(8) = +9 dB -> about 33 dBA at one metre
Those conversions are mine, not a vendor’s, and they assume a free field. A real room has walls, a real case has panels that resonate, and a desk is not a hemisphere. Use them to compare drives, not to predict a room.
Two further caveats make the published number optimistic. First, vendors explicitly exclude pure tones: Seagate measures overall A-weighted acoustic sound power levels with no pure tones, and follows ECMA-74 for identifying prominent discrete tones, using the ISO 389-7 absolute threshold of hearing to decide whether a tone is audible. A drive emits a tone at its rotation frequency - 90 Hz at 5,400 rpm, 120 Hz at 7,200, 167 Hz at 10,000, 250 Hz at 15,000 - and the ear locks onto tones in a way it does not lock onto broadband noise. A figure that has had the tones taken out understates the annoyance of a tonal drive.
Second, the seek figure is measured at a defined seek rate rather than at saturation. Both vendors publish the formula:
Seagate: seeks per second = 0.4 / (average latency + average access time)
WD: dwell time = 0.5 x 60 / RPM
seek rate = 0.4 / (average seek time + dwell time)
At 7,200 rpm the dwell term is 0.5 x 60 / 7200 = 4.17 ms, so with a plausible
8 ms average seek - my assumption, not a published figure for this drive -
the rate is 0.4 / 0.01217 = 33 seeks per second. A resilver drives a nearline
disk considerably harder than that, so the acoustic seek number is a moderate
workload rather than a worst case.
Between the two effects, a datasheet bel figure understates a drive grinding through a scrub in a cupboard next to a bedroom. Nobody should put a 15K drive in a room where somebody sleeps, and the reason is tonal rather than loud. Note also the 0.8 bel gap between Seagate’s and Western Digital’s idle figures for comparable drives, a factor of about 6 in acoustic power from two manuals both citing ISO 7779: the fixture and the definition of idle differ enough that cross-vendor acoustic comparison is not sound.
10K and 15K drives are finished, and idle watts per terabyte is why
Their reason to exist was rotational latency, which averages half a revolution:
| Spindle | Revolution | Average rotational latency |
|---|---|---|
| 5,400 rpm | 11.11 ms | 5.56 ms |
| 7,200 rpm | 8.33 ms | 4.17 ms |
| 10,000 rpm | 6.00 ms | 3.00 ms |
| 15,000 rpm | 4.00 ms | 2.00 ms |
The published average latencies agree: 4.16 ms for the Exos X24, 2.9 ms for the Exos 10E2400, 2.0 ms for the Exos 15E900. The entire distance from nearline to 15K is 2.16 ms, and an SSD serves a read in tens to a few hundred microseconds. Flash beats the whole column by an order of magnitude or more, which is why these drives stopped being developed. The full latency derivation is in HDD or SSD.
Capacity is the second argument and it is brutal. The Exos 10E2400 family tops out at 2.4 TB, with four disks and eight heads at that capacity; the Exos 15E900 family tops out at 900 GB with three disks and six heads. Both are 2.5-inch. Sustained transfer is 266 down to 130 MB/s for the 10K and 300 to 210 MB/s for the 15K, or 315 to 215 MB/s on the Fast Format models.
Energy is the third, and it decides it:
idle watts per terabyte, from the figures above
Exos X24 24 TB 0.259 W/TB
Exos 10E2400 2.4 TB 2.042 W/TB 7.9 times worse
Exos 15E900 900 GB 6.333 W/TB 24.4 times worse
Seagate’s own datasheet for the 10E2400 publishes a Performance Efficiency Index of 0.0020 idle watts per gigabyte, which is the same 2.04 W/TB by another unit. Over five years the 15K drive spends 277 kWh per terabyte of capacity just sitting there, which at any domestic tariff exceeds what the drive cost.
Two things they still win, stated fairly. The unrecoverable read error rate is 1 per 10^16 rather than 1 per 10^15, a genuine order of magnitude. And the published AFR is 0.44 per cent, against nearline 0.35 - worse on paper, but these are drives specified for a different duty.
One provenance detail specific to these: the Exos 15E900 datasheet carries a footnote that the warranty period is either five years or when the device reaches the total TBW over the warranty period, whichever comes first. These models contain NAND for caching, which is why a spinning drive has a TBW clause at all. On a used purchase that clause is moot, but it tells you the drive has flash inside it with its own wear.
They are cheap because they are finished. They hold far less per drive than a nearline 7,200 of the same vintage, which is the number this site ranks on, and they cost more to own per terabyte than they cost to buy.
Used enterprise SSDs, where the capacity number names the tier
The used enterprise SSD market decoupled from the new market during 2025 and 2026, for the same supply reason as the drives: secondhand volume follows decommissioning schedules, not NAND contracts. Through 2026 a used enterprise SATA or SAS SSD at 3.84 TB has run at roughly a quarter to a third of the price per terabyte of new NVMe U.2, and has undercut a new 4 TB consumer SATA drive by more than half. Neither ratio is steady enough to publish as a number, and an earlier version of this section published both with dates attached and no reporter named, which reads as a measurement when it is not one. Take the current spread from the SSD listings on the day you read this, the same way the hard-drive ratio earlier in this article should be taken from the listing pages rather than from the article.
The capacity number tells you the endurance tier
This is the most useful piece of pattern recognition on a listing page, and it falls straight out of the vendors’ own capacity ladders. Kioxia’s product briefs:
| Tier | Rating | Capacities |
|---|---|---|
| PM7-R, read-intensive | 1 DWPD | 1,920 / 3,840 / 7,680 / 15,360 / 30,720 GB |
| PM7-V, mixed-use | 3 DWPD | 1,600 / 3,200 / 6,400 / 12,800 GB |
| PM6-M, write-intensive | 10 DWPD | 400 / 800 / 1,600 / 3,200 GB |
3,840 / 3,200 = 1.2
1,920 / 1,600 = 1.2
7,680 / 6,400 = 1.2
15,360 / 12,800 = 1.2 exactly, every time
A drive whose capacity is a round binary multiple of 400 or 480 GB is telling you its over-provisioning. The extra 20 per cent of NAND on the mixed-use part is not sold to you; it is spare area for the controller, which is what buys the higher rating. The full mechanism, and how over-provisioning converts into write amplification, is derived in SSD endurance.
Read the table again before trusting the capacity too far, though. 1,600 and 3,200 GB appear on the mixed-use ladder and on the write-intensive one, so the 1.2 ratio separates the over-provisioned tiers from the read-intensive tier and does not separate 3 DWPD from 10. Those two capacities narrow a drive to one of the two endurance tiers; the model name decides which of them it is.
Now the arithmetic that decides which one to buy, over the five-year warranty:
lifetime writes = capacity x DWPD x 365 x 5
PM7-R 3.84 TB x 1 x 1,825 = 7,008 TB = 7.0 PBW
PM7-V 3.20 TB x 3 x 1,825 = 17,520 TB = 17.5 PBW
PM6-M 1.60 TB x 10 x 1,825 = 29,200 TB = 29.2 PBW
The mixed-use drive holds 17 per cent less data and accepts two and a half times the writes. If you are buying for a ZFS special vdev, a database, or anything doing sustained small writes, that trade is the whole decision. If you are buying bulk flash for media, the read-intensive part is strictly better value per terabyte and the endurance is irrelevant.
Against consumer drives the gap is roughly three to one at the same capacity: about 7,000 TBW on a 4 TB-class enterprise drive against about 2,400 TBW on a consumer equivalent, which is why a used enterprise SSD at 20 per cent wear still has more writing left in it than a new consumer drive has in total:
7,008 TB x 0.80 = 5,606 TB remaining against 2,400 TBW new consumer
What else the enterprise part carries
The Kioxia briefs specify power loss protection and end-to-end data protection including T10 DIF, a 24G SAS interface with single and dual-port support, 2,500,000 hours MTTF, a five-year limited warranty, typical ready power of 5 W, and interface speeds from 1.5 up to 22.5 Gbit/s. Power loss protection is the one that has no consumer equivalent at any price: capacitors that let the controller flush its write buffer when the rail drops, which is what makes a synchronous write honest.
The security options are worth reading carefully, because one of them is the locking problem from earlier in this article. Kioxia offers SIE, sanitize instant erase, which is a T10 crypto erase; SED, which the footnote states supports TCG Enterprise SSC; and FIPS SED. That is precisely the class sedutil cannot unlock. An SED-optioned enterprise SSD pulled from an array without a cryptographic erase is the hardest single item on the used market to recover.
Reading the wear, which is not standardised
NVMe is the easy case because the specification defines it. The SMART/Health Information log, log identifier 02h, defines Percentage Used as a vendor-specific estimate of the percentage of NVM subsystem life used, where 100 means the estimated endurance has been consumed but may not indicate a failure. The value is allowed to exceed 100, percentages above 254 are reported as 255, and the field is updated once per power-on hour. Data Units Written counts 512-byte units reported in thousands, so a value of 1 means 1,000 units of 512 bytes.
SATA and SAS SSDs are the hard case. Backblaze’s analysis of their own SSD fleet found that only five of the 44 SMART attributes were common between three SSD models. The life-remaining attribute alone differs by vendor: Western Digital uses attribute 169 counting down from 100, Crucial uses 202 counting up to 100, and Seagate uses 231 with a replacement threshold of 10. Attribute 173 is wear levelling, 174 is unexpected power loss count, 241 and 242 are total LBAs written and read on Seagate and WD parts, and 246, 247 and 248 carry host sectors written and NAND pages written on Crucial parts.
A “98 per cent health” figure in a listing is therefore a number produced by somebody’s tool guessing which attribute meant what. Ask for the raw output.
OEM firmware works, and the warranty is what you are actually giving up
A drive pulled from a Dell, HPE, IBM or NetApp chassis usually carries that vendor’s firmware rather than the manufacturer’s.
- It usually just works on a plain HBA in IT mode. The OEM firmware changes defaults, not the command set, which is why an OEM-branded pull is worth buying at the discount it carries. It is not what causes the discount. The warranty is, below.
- You cannot update the firmware, and the reason is cryptographic. The Exos X24 SATA manual states that the drive only accepts download files which have been cryptographically signed by the appropriate Seagate Design Center, and lists three conditions that must all hold: the file must be an SED file where a standard non-SED file is rejected, it must be signed and authenticated, and it must match the correct drive model with a compatible revision and customer status. “Customer status” is the OEM lock. It is not a policy somebody could waive for you.
- Putting it back into that vendor’s controller can be fussy. The best-documented case is HPE, whose servers warn about drives lacking their firmware signature. Behaviour differs by vendor and generation; the only reliable test is the machine in front of you.
- Defaults may differ. Write cache, power management and queue depth are set
by firmware. Check with
sdparm -a /dev/sdXon SAS,hdparm -Won SATA. - The caddy is not universal. A Dell sled does not fit an HPE chassis.
The warranty is usually not yours
Seagate’s warranty terms state that OEM warranties extend only to the OEM and may not be assigned or transferred without Seagate’s consent. In practice OEM serial numbers frequently do not appear in the consumer warranty checker at all and return “not covered”. Seagate’s check needs the drive serial number, the model or part number, and the country of purchase, so it is a thing you can do before bidding if the listing shows a label.
That is the legal reason an OEM-branded pull is cheaper, and it is a real discount for a real loss rather than a trick.
Two related clauses catch sellers who relabel. The Exos manual states that factory-installed labels must not be removed or covered with additional labels, that removal voids the warranty, and that some factory-installed labels contain information needed to service the drive. It also states that any unauthorised repair or tampering with the factory seal voids the warranty. A drive arriving with a seller’s own sticker over the manufacturer’s label has lost whatever entitlement it had, and has also lost the PSID you may need later.
Western Digital encodes the answer in the model number
This is the single best piece of label-reading available, and it is documented in
the HC580 manual’s own “How to Read Model Numbers” section. Taking
WUH722424ALE6L4:
| Segment | Meaning |
|---|---|
W |
Western Digital |
U |
Ultrastar |
H |
Helium |
72 |
7,200 rpm |
24 |
Maximum capacity of the family, in TB |
24 |
This drive’s capacity, in TB |
A |
Generation |
L |
26.1 mm z-height |
E6 |
512e, SATA 6 Gb/s |
L |
Power disable on pin 3: 0 supports it, L is legacy pin 3 |
4 |
Data security mode: 1 is SED/TCG Enterprise, 4 is base, no encryption |
The last two characters answer the two questions this article spends the most
words on. A trailing 4 means the drive has no encryption to be locked out of
and supports sanitize overwrite only. A trailing 1 means TCG Enterprise SSC,
with sanitize crypto scramble and crypto erase - and the possibility of arriving
locked. The character before it tells you whether the 3.3 V pin will stop the
drive spinning up on your power supply.
That is two significant risks readable off a label photograph, before you bid.
The 3.3 V pin is a circuit board difference, not a setting
SATA revision 3.3, published in February 2016, redefined pin 3 of the 15-pin power connector - one of its three 3.3 V pins - as PWDIS, power disable. Assert 3.3 V on it and a drive implementing the feature stays unpowered. The orange wire in a native SATA power lead does exactly that.
Western Digital’s technical brief on the feature is unusually direct about the implementation, and it corrects two pieces of common folklore.
It is a different circuit board, not a firmware option. The brief states that the feature requires a unique PCBA on the SATA drive, that if you want it you must specifically order it, and that the feature is hard wired: sending a high level signal to pin 3 causes special circuitry on the drive to physically remove power to the system-on-chip, and this external circuitry cannot be configured by firmware. So no firmware update adds or removes it, and no jumper disables it. The first WD SATA product to offer it was the Ultrastar DC HC510.
SAS drives are immune, and the reason is historical. SAS never defined an alternate usage for pin 3, so legacy systems leave it as a no-connect. With SATA the story differed: some legacy power supplies tied pins 1, 2 and 3 together to 3.3 V, leaving pin 3 permanently high and sending what amounts to a permanent hard reset to any drive implementing the feature.
No damage results either way. The brief is explicit that the only side effect is that the drive will not spin up. A silent drive on a modern PSU is not a drive you have broken.
Two standard fixes. A Molex-to-SATA power adapter, since four-pin Molex carries only 5 V and 12 V and has no 3.3 V rail to assert. Or polyimide tape over the first three contacts at the narrow end of the L, all three of which are 3.3 V and none of which is needed. Use Kapton rather than electrical tape, which creeps when warm. Many modular PSU cables omit the orange wire anyway, in which case there is nothing to fix and nothing to do.
Check this before opening a return on a silent drive, and check the model number before buying. Drive interfaces covers the same pin from the shucking angle.
Pricing a pull against the life it has left
The arithmetic has four terms and only one of them is in the listing.
five-year cost per terabyte
delivered price / capacity from the listing table
+ (HBA + cables) / (drives it will ever hold) / TB amortised, not per drive
+ 2.27 kWh/TB/year x 5 x your tariff nearline, from the table above
+ a risk load for the copies you will need anyway not optional
The third term is the one people leave out and it is frequently the largest. At 2.27 kWh per terabyte per year, a nearline drive run continuously for five years consumes 11.4 kWh per terabyte of capacity. Compare that against the delivered price per terabyte on the listing page and see which is bigger at your tariff. On a 10K drive at 17.89 kWh/TB/year the same figure is 89 kWh per terabyte, and on a 15K drive 277 kWh. The energy term is what kills the performance classes, not the purchase price.
For the life left, use two axes rather than one, because the specifications do:
calendar axis
rated service life 5 years = 43,800 power-on hours at 24x7
hours on the drive from SMART, or the background scan page on SAS
Backblaze field evidence flat failure rate to about 10 years
rate axis
workload rate = (lifetime reads + lifetime writes) x 8,760 / power-on hours
against less than 550 TB/year specified
your intended rate: a home NAS writing 2 TB/month is 24 TB/year, 4% of it
A drive at 43,800 hours and 4 per cent of its rated workload rate is not a drive at the end of its life. It is a drive that has used its calendar and almost none of its duty. That is the trade this whole market is built on, and it is only visible if you compute it.
Be honest about what the model cannot tell you. The hazard rate for an individual used drive is not knowable - both vendors say so in their own manuals, the fleet data disagrees with the specification by a factor of four, and the drive’s handling in transit is a variable nobody measures. The model prices the running cost, which is knowable. It does not price the risk, which is why the fourth term exists and why the answer is always redundancy rather than a better drive.
What to do with this on a listing page
- Sort all drives by price per terabyte and start at the top, then read back up this article for the drive you land on. The ranking is delivered cost; everything above is what it does not include.
- Filter SAS only after you have an HBA, or have budgeted one. Add the card, the cables and a PCIe slot to the price of the first drive and amortise it across every drive it will ever hold, not just this one.
- On a spinning drive, filter to a stated sector format
before you buy, and if a SAS listing does not state one, plan for
sg_formatand a day of waiting. Verify withsg_readcap -lon arrival:Logical block length=520means reformat,prot_en=1at 512 bytes means it already works. - Read the model number for the two risks. On a Western Digital Ultrastar the penultimate character is the 3.3 V power disable pin and the last is the security mode. A listing photograph of the label is worth more than the description.
- Ask for
smartctl -abefore bidding, and compute the workload rate yourself from gigabytes processed and power-on hours. Four per cent of the rated 550 TB/year is a good drive; forty per cent is a different purchase. - Treat “grown defect list” and attribute 187 as hard stops. Anything above zero on a drive you have not yet paid for is a reason to move to the next listing.
- Stay at 7,200 rpm and below. A 10K or 15K drive costs seven to twenty-four times as much per terabyte in idle energy alone, and its only remaining advantage is an error rate you can get from redundancy instead.
- On SSDs, read the capacity before the description. 1.92 or 3.84 TB is read-intensive at 1 DWPD; 400 or 800 GB is write-intensive at 10 DWPD; 1.6 or 3.2 TB is mixed-use or write-intensive, at 3 DWPD or 10, because both ladders carry those two capacities and only the model name separates them. Browse SSDs or NVMe and let the number narrow the tier rather than name it.
- Exclude auctions while you are learning what a model is worth, so you are comparing prices somebody can actually pay today rather than bids that have not finished rising.
- Buy into an array, never as the only copy of anything. Every number in this article is a population statistic or a bound, including the good ones.
The rest is the sum in the section above: delivered price per terabyte, plus the controller amortised, plus the kilowatt-hours over the years you plan to run them, against the same sum for a new consumer drive with a warranty you can actually claim. Enterprise pulls usually win, sometimes by a lot, and never by as much as the headline price suggests.