Disk Wipe Time: A Throughput and Verification Model

Short answer

For sequential host overwriting followed by full read verification, estimate the phases separately: bytes written divided by sustained write rate, plus bytes read divided by sustained verification rate. Add preparation, synchronization, review and exception handling explicitly. A capacity divided by a headline interface speed is not a defensible completion estimate.

This is a planning model for host I/O, not a rule for controller-internal block erase or cryptographic erase. It predicts elapsed work under stated assumptions; it cannot prove sanitization coverage or successful completion.

Who this is for

This guide is for authorized teams scheduling an already-approved overwrite and verification procedure. It does not recommend extra overwrite passes or require full readback for every method. Let the applicable policy choose the technique and verification scope before estimating its cost.

Use an actual byte count for the selected address range, not an ambiguous capacity label. Keep TB versus TiB and MB/s versus MiB/s consistent. In the examples, 1 TB = 10^12 bytes and 1 MB/s = 10^6 bytes per second. A mebibyte is 2^20 bytes; substituting one unit for another changes the estimate.

Derive the sequential phase model

For one phase with an effective average rate R, transferring B bytes takes B/R seconds. If phases run one after another, their durations add. For equal full-range passes, define:

• B: bytes in the approved host-visible range.
• Pw: number of full overwrite passes, a nonnegative integer.
• Pr: number of full read-verification passes, a nonnegative integer.
• Rw: effective sustained write rate in bytes/second, positive.
• Rr: effective sustained verification-read rate in bytes/second, positive.
• H: additional non-overlapping preparation, synchronization and review time in seconds, nonnegative.

Then the simplified estimate is:

T_io = Pw * B / Rw + Pr * B / Rr
T_job = T_io + H

The units check is straightforward: a dimensionless pass count times bytes divided by bytes/second gives seconds. Adding phases preserves that unit.

If passes cover different ranges or use different rates, replace the repeated terms with a sum over the actual phases. Do not call a partial sample a full pass. If Pr=0, the equation omits full readback; that arithmetic choice does not establish that the remaining verification procedure is adequate.

Worked example: four decimal terabytes

Assume a hypothetical B=4,000,000,000,000 bytes, sustained writes at 200,000,000 bytes/second and sustained verification reads at 250,000,000 bytes/second. These rates are illustrative inputs, not measurements or a drive specification.

One overwrite takes 20,000 seconds. One full verification read takes 16,000 seconds. Sequentially they total 36,000 seconds, or exactly 10 hours. Adding an assumed half-hour of non-overlapping overhead gives 10.5 hours.

Changing to three writes with one final verification gives 76,000 seconds, or 21 hours 6 minutes 40 seconds, before overhead. Verifying after every one of those three writes gives 108,000 seconds, or 30 hours. These are different schedules; “three passes” does not describe both accurately.

This Python 3 example performs arithmetic only. It does not open a disk, benchmark storage or initiate a wipe:

def estimate_seconds(B, Pw, Pr, Rw, Rr, H=0):
    if B < 0 or H < 0 or Rw <= 0 or Rr <= 0:
        raise ValueError("Invalid size, rate or overhead")
    if any(not isinstance(p, int) or p < 0 for p in (Pw, Pr)):
        raise ValueError("Pass counts must be nonnegative integers")
    return Pw * B / Rw + Pr * B / Rr + H

B = 4_000_000_000_000
for Pw, Pr in ((1, 1), (3, 1), (3, 3)):
    seconds = estimate_seconds(B, Pw, Pr, 200_000_000, 250_000_000)
    print(Pw, Pr, f"{seconds:.0f}", f"{seconds / 3600:.6f}")

The calculated output is 1 1 36000 10.000000, 3 1 76000 21.111111 and 3 3 108000 30.000000. None is a promised completion time for a real device.

Why an effective rate matters more than a peak number

An interface's advertised bandwidth can exceed the sustained rate of the medium, controller, bridge, host or comparison pipeline. Short bursts may also reflect cache behavior rather than a complete-range operation. A verification phase includes reading and comparing data; its effective rate can be lower than a standalone sequential-read benchmark.

Use phase-level elapsed time and completed byte counts from an authorized representative job. Document the connection, workload and software. Do not benchmark by writing to a drive whose data must be retained, or add a destructive measurement merely to fill in this model.

If a phase's rate changes across regions, sum regional durations rather than averaging regional MB/s values indiscriminately. For equal-sized regions at different speeds, the slow region consumes more time; a simple arithmetic average of those speeds can understate duration. The full-phase effective rate is completed bytes divided by actual elapsed phase time.

Express uncertainty as scenarios

Suppose the same hypothetical four-terabyte one-write/one-read job uses writes between 100 and 200 MB/s and reads between 150 and 250 MB/s. Under those assumed effective-rate scenarios, I/O time ranges from 10 to approximately 18.52 hours before overhead.

That range is a sensitivity analysis, not a statistical confidence interval or a guaranteed upper bound. Device errors, retries, thermal behavior, connection loss or an interrupted run can exceed it. Track exceptions separately instead of hiding them inside a falsely precise average.

For remaining time during a sequential phase, estimate the unfinished bytes in that phase at its relevant sustained rate, then add later phases and remaining overhead. A write-phase progress percentage cannot automatically represent progress through the entire job including verification and review.

Where this model stops applying

Do not estimate a controller-internal sanitize action using host write bandwidth unless the manufacturer explicitly establishes that relationship. Dedicated block erase and cryptographic erase use different mechanisms. Obtain the device's supported status, estimates and completion procedure instead.

Multiple drives can share a bridge, host link or controller. Multiplying one isolated drive's rate by the number of attached drives can overstate aggregate throughput. Likewise, overlapping preparation or verification changes the sequential assumption. Model the actual schedule before subtracting time for supposed parallelism.

When to use this

Use the model to compare approved schedules, size a maintenance window or explain why verification materially changes elapsed time. Keep the technique and required evidence fixed while comparing performance scenarios.

When not to use this

Do not use a fast estimate to justify skipping required verification, adding unnecessary passes or accepting a failed operation. A timestamp deadline is not proof that the requested data became inaccessible.

Workflow

1. Record the approved range in bytes and the exact phase sequence.
2. Obtain representative sustained phase rates with units and provenance.
3. Compute each phase, then add only non-overlapping overhead.
4. Show an explicit slower scenario and a separate exception path.
5. Compare the completed job's phase evidence with the estimate and update future assumptions.

Verification note: reproducible calculations only

No storage device was benchmarked or wiped for this article. The examples are mathematical scenarios. Before using the model operationally, check byte counts, units, phase order, rate provenance and whether concurrency or device-internal behavior invalidates the assumptions.

Verification checklist

• Rates and capacities use compatible byte units.
• Write and verification counts reflect the actual procedure.
• Effective rates include the work attributed to each phase.
• Overhead is neither omitted nor counted twice.
• Actual completion and acceptance are established independently of the estimate.

Resale and evidence checklist

Keep estimated and measured durations in separate fields beside the operation's result. A job that ran for the predicted duration can still fail; a job that finishes sooner can be legitimate if the approved technique and evidence support it.

What not to publish

Do not expose customer data or sensitive asset identifiers when sharing timing examples. Label hypothetical inputs clearly rather than presenting them as a product benchmark.

Common mistakes

Avoid mixing bits with bytes, treating an interface peak as a sustained verification rate, counting only writes or interpreting a scenario range as a confidence guarantee. Do not transfer host-overwrite arithmetic directly to cryptographic erase.

CliDeck workflow fit

Use explicit phases, assumptions and completion evidence in an asset-processing workflow. This model is not a CliDeck benchmark, feature claim or estimate for unreleased software.

FAQ

Does a larger pass count always make the right sanitization method?

No. Method suitability and scope come first. The equation only prices the host I/O you specify.

Is a manufacturer estimate a completion signal?

No. Keep estimated duration separate from actual operation status and acceptance evidence.

Related guides

The NVMe scope and completion guide explains why command acceptance and completion differ. The HDD sampling analysis covers the separate question of what a partial verification sample can establish.

Safety note: This guidance applies only to devices your team owns or is authorized to process. Use the approved, device-specific procedure, customer policy, and your organization’s sanitization and evidence procedures.