Drive Endurance Fit — methodology

Contents

1. What it decides, and what it does not
2. Inputs
3. The write-rate math
4. The four checks
5. Verdict and ranking rules
6. Class E engineering defaults
7. The drive registry and its sources
8. Evidence classes and confidence
9. What invalidates a result
10. Method changelog

1. What it decides, and what it does not

The engine answers one procurement question: for this camera wall, at this retention, will this drive — or the best drive in the registry that matches your interface and media — hold the recording, stay inside the endurance the vendor rates it for, cover the service life you plan, and keep up with the peak write rate? It returns FIT, FIT WITH RISKS, NEEDS VALIDATION or NO FIT.

It does not predict a failure date, an annualised failure rate or remaining flash life. Those depend on temperature, vibration, power events, firmware and the actual write pattern, none of which a datasheet figure captures. The design decision behind this engine is the same one behind the Thermal Feasibility Checker: a categorical answer from the vendor's own numbers is honest; a predicted lifetime from a form is not.

It is also not the Storage Endurance engine, which sizes an array from a retention target. This one starts from a specific drive model — or the whole registry — and asks whether the vendor's published endurance survives your write load.

2. Inputs

Nothing is required. Naming a drive pins the result to that model and the candidate list holds one row; leaving it out ranks every row that matches interface and media and reports the winner.

3. The write-rate math

The per-camera bitrate comes from the shared camera-bitrate table — the same table the Network Bandwidth and Storage Endurance engines use, scaled from its 30 fps baseline to the frame rate you gave. From there:

• total_avg_mbps = cameras × per-camera average Mbps
• duty = recording is motion ? motion_share : 1
• TB/day = total_avg_mbps × duty × 86400 / 8 / 1e6 × write_amplification — decimal terabytes, the unit vendors rate endurance in
• TB/year = TB/day × 365
• capacity needed TB = (TB/day without write amplification) × retention_days
• peak write MB/s = total peak Mbps / 8 — no duty factor: motion recording lowers the volume written, not the rate when cameras trigger together

Write amplification is deliberately absent from the capacity figure: the amplified bytes are written and discarded, not retained, so they consume endurance but not shelf space. The peak side uses the peak of the camera-bitrate band rather than the average, because a write path has to survive the burst, not the mean.

4. The four checks

Capacity, endurance and throughput take their status from utilization against the shared thresholds: PASS below 0.8, NEAR LIMIT from 0.8, FAIL at 1.0 and above. The service-life check is categorical instead, because the two media rate endurance differently: an HDD's annualised workload rating is a rate ceiling that has to hold in every one of the service years, so the check passes when the annual load stays under the rating; an SSD's TBW is a budget, so the check passes when years-to-limit reaches the service life. A drive that publishes no endurance figure at all reports UNKNOWN on both the endurance and the service-life check rather than being scored on a guess.

5. Verdict and ranking rules

• Any check FAILs → NO FIT.
• Else any check is UNKNOWN → NEEDS VALIDATION.
• Else any check is NEAR LIMIT → FIT WITH RISKS.
• Else FIT.

With filters rather than a named drive, every matching row is evaluated and ranked by verdict first, then by years-to-limit descending, then by the capacity closest above the retention footprint (a drive that does not hold the footprint sorts last on that key). The winner's verdict is the result's verdict; the top ten rows travel with it as candidates, and the alternatives block names the smallest model that still fits and the longest-life model in the registry at this load.

Every non-PASS check that has a fix lists it in remediations: add drives, shorten retention, record on motion, move to a higher-endurance class, or plan a replacement at the year the budget runs out. The primary_bottleneck is the constraint with the highest bottleneck score — utilization × status severity × confidence weight — which is the one that breaks first as the wall grows.

6. Class E engineering defaults

Both are class E engineering figures. They are named as such in the assumptions of every result that uses them, and both are overridable from the Advanced panel and from the API. Nothing else in the engine is an estimate: every capacity, endurance, warranty and transfer-rate number comes from a vendor datasheet.

7. The drive registry and its sources

Thirty models across four classes, every row carrying the vendor datasheet or product brief it was read from, with a verbatim quote and a link:

A source record without a resolvable URL is dropped when the registry is built, and a row left with no source at all is dropped and listed in the dataset's gaps. Known holes travel with every result: no vendor MSRP could be quoted for any row, so price_usd is null throughout; the industrial M.2 class is empty because no vendor datasheet for those parts was reachable; HDD sequential figures are recorded as the sustained-transfer rate the vendor publishes rather than invented read/write numbers; and a handful of SSD power figures are null because the datasheet text carries no watt values.

8. Evidence classes and confidence

• A — every drive figure: capacity, TBW, DWPD, annualised workload rating, warranty, MTBF, sequential-write and sustained-transfer rates, operating range.
• C — the camera-bitrate table the write rate starts from: empirical per-camera figures, not vendor specifications.
• D — the service-life check, which divides a class A endurance budget by a derived annual load.
• E — the write amplification and the motion share, and any check whose vendor figure is missing (reported UNKNOWN).

Confidence: HIGH for capacity, endurance and throughput when the datasheet publishes the figure; MEDIUM for the derived service-life check; LOW for any UNKNOWN. The overall confidence is the lowest of the four.

9. What invalidates a result

• A real motion share above the one you entered — the default 0.3 is a planning figure, not a measurement of your site.
• A write path with more amplification than 1.1: small-file recording, database-backed event storage, copy-on-write snapshots or RAID 5/6 parity writes all raise it.
• Cameras whose real bitrate is above the table's band: high-motion scenes, low-light noise, poor encoder tuning or CBR at a rate above the table.
• Recording and re-encoding on the same node — the engine models the recorded stream only.
• Operating a drive outside its rated temperature range, which the registry records but no check enforces.
• Reads sharing the same drive: the throughput check budgets writes only.
• Any figure the datasheet does not publish — the check reports UNKNOWN and the verdict becomes NEEDS VALIDATION rather than a number.

10. Method changelog

Method changes bump the method version; new or re-verified drive rows bump the dataset version. Both are in every result and in the citation block.