Multi-Drive Wiping: A Capacity and Shared-Bandwidth Model

Short answer

Adding wiping bays helps only while an additional bay can receive useful service from the rest of the system. For a host-driven overwrite followed by read verification, both occupied bays and shared data-transfer capacity constrain the batch. A four-bay bench is not necessarily four times as fast as a one-bay bench.

This article proposes a simple capacity-planning model. It gives conditional lower bounds and necessary queue-load limits, not a completion-time promise, a sanitization standard or a physical law. It does not establish that a selected wiping method is appropriate or that any drive was successfully sanitized.

Who this is for

This model is for operators planning an authorized multi-drive processing station and reviewers evaluating optimistic throughput claims. Its scope is deliberately narrow: identical jobs, each performing a host-transferred overwrite and a subsequent read-verification phase while occupying one bay throughout.

It does not directly model device-internal sanitize or cryptographic erase. Those operations may keep a bay occupied while transferring little host payload. Nor does it model parallel paths with separate read and write capacities as one simple pipe. Choose the workload before choosing the formula.

When to use this

Use the model to reject impossible schedules, identify which resource deserves measurement, and decide whether additional bays might help. It is most useful before committing to an output target or comparing configurations with the same method and verification policy.

Record where measurements come from. A per-drive rate from an isolated test and an aggregate rate measured under concurrency answer different questions. Do not mix a burst result with a sustained full-workload assumption without stating that limitation.

When not to use this

Do not use the result as an erase certificate or as evidence of inaccessible-area coverage. Do not shorten required verification to make a capacity target fit. Method selection and acceptance remain independent decisions.

Do not benchmark unknown customer disks simply to fill missing inputs. A storage load generator can modify data depending on its configuration. Obtain an authorized workload and target plan separately; this article includes only pure arithmetic code.

Workflow

1. Define the work and units

For each identical job, define:

Symbol	Meaning	Unit
W	Host write payload required by the chosen procedure	bytes/job
V	Host read payload required by its verification procedure	bytes/job
r_w	Upper-bound sustained write rate available to one isolated job	bytes/second
r_r	Upper-bound sustained read rate available to one isolated job	bytes/second
H	Upper-bound aggregate payload service rate of the shared bottleneck	bytes/second
k	Number of simultaneously occupied processing bays	bays
n	Number of jobs in the batch	jobs

The payload definition must match the resource. Here H measures combined read and write payload crossing one shared capacity budget; it is not the advertised line rate or a full-duplex rating added without analysis. Protocol overhead is excluded from payload and must already be reflected in the usable rate assumption.

Use decimal bytes consistently. In the example, one TB means 10^12 bytes and one MB/s means 10^6 bytes/second. A tool reporting MiB/s needs conversion before comparison. W and V express the selected workload, not an instruction that every method requires these phases.

2. Derive the isolated-job time bound

If the write phase moves W bytes no faster than r_w, it needs at least W/r_w seconds. The later read phase similarly needs at least V/r_r seconds. Because these phases are sequential for one job, add their times:

t0 = W / r_w + V / r_r
D = W + V

Here t0 is seconds per job and D is bytes per job. Setup, identity checks, retries, review and handoff are omitted, so this is an optimistic service-time floor under the stated rate bounds. It is not a measured duration.

If the rates are merely representative averages rather than defensible ceilings, treat t0 as a scenario baseline rather than a strict lower bound. State that change in interpretation instead of retaining stronger language than the inputs support.

3. Derive the batch bounds from resource accounting

The batch requires at least n times t0 bay-seconds. During elapsed time T, k bays can supply at most k times T bay-seconds. Therefore T must be at least n times t0 divided by k.

The shared resource must also serve n times D bytes. It can serve at most H times T bytes in elapsed time T. Dividing gives another necessary bound. A batch containing at least one job also cannot finish before its isolated-job floor:

T_batch >= max(t0, n * t0 / k, n * D / H)

Each term has units of seconds. Taking the maximum is necessary because both resources constrain the same batch; adding the two resource bounds would generally double-count time during which they operate together.

This is not a constructive schedule. It does not guarantee that a scheduler can achieve the bound. Discrete job waves, phase ordering, unequal drives, thermal behavior and contention can all increase elapsed time. The bound assumes that r_w, r_r and H remain applicable over the modeled workload.

4. Work a numerical example

Consider a fictional eight-drive batch with four bays. Each job writes 4 TB and then reads 4 TB. Assume per-job ceilings of 200 MB/s write and 250 MB/s read, plus a combined shared payload ceiling of 600 MB/s.

The isolated-job floor is 20,000 plus 16,000 seconds: 36,000 seconds, or ten hours. Eight jobs require at least twenty elapsed hours of four-bay capacity. The shared resource must carry 64 TB, requiring 106,666.67 seconds, or about 29.63 hours.

The model therefore gives a batch lower bound of about 29.63 hours. Doubling the bays to eight does not change that shared-resource term. Increasing H to 1,200 MB/s with four bays moves the larger constraint back to the twenty-hour bay bound. Neither scenario includes setup, failures or review.

These values are illustrative assumptions, not hardware benchmarks, observed wipe durations or product specifications.

5. Add a necessary arrival-rate check

For a continuing queue, let lambda be the average arrival rate in jobs per second. Every arriving job consumes at least t0 bay-seconds and D shared bytes. To leave capacity headroom in this idealized load test, require:

lambda * t0 < k
lambda * D < H
lambda < min(k / t0, H / D)

These strict inequalities are planning headroom conditions, not a proof of queue stability. Equality leaves no room for variability; passing the test does not account for outages, scheduling or a slow job distribution. No Poisson-arrival assumption or waiting-time formula is being asserted.

For the original example, k/t0 is 0.4 jobs/hour and H/D is 0.27 jobs/hour. Arrivals of 0.3 jobs/hour already exceed the shared-resource limit. The model flags the plan as incompatible with those assumptions; it does not predict the exact queue length or customer wait.

6. Check the arithmetic without touching storage

This standard-library Python example evaluates only the fictional case:

from fractions import Fraction

n, k = 8, 4
W = V = 4 * 10**12
rw, rr, H = 200 * 10**6, 250 * 10**6, 600 * 10**6

t0 = Fraction(W, rw) + Fraction(V, rr)
D = W + V
batch_seconds = max(t0, n * t0 / k, Fraction(n * D, H))
capacity_per_hour = min(Fraction(k, 1) / t0, Fraction(H, D)) * 3600

print(round(float(batch_seconds / 3600), 4))
print(round(float(capacity_per_hour), 4))

Expected arithmetic output is 29.6296 hours for the bound and 0.27 jobs/hour for the idealized capacity ceiling. The code neither discovers devices nor issues reads, writes or erase commands. Changing an input does not validate it against a physical system.

7. Measure the correct boundary

An authorized performance study should record target type, path, concurrency, workload, cache policy, duration, software version and sustained results. DiskSpd distinguishes file and device targets and exposes workload/concurrency controls; those choices affect what a benchmark measures. A filesystem-path result must not silently become a physical-drive treatment claim.

After measurement, compare actual bottlenecks with the assumed shared resource. If read and write have independent budgets, or the process uses an internal sanitize command, replace this single-pipe model. Do not force a different architecture into H just to preserve a convenient equation.

Verification checklist

• Are payload and rate units consistent, with decimal/binary conversion explicit?
• Is the operation host-driven and sequential per job as assumed?
• Are rate inputs ceilings, scenario baselines or actual observations, clearly labeled?
• Does H represent the actual shared payload boundary?
• Are interruptions, retries, setup and acceptance review handled outside the optimistic bound?
• Is per-asset sanitization evidence independent of the capacity calculation?

Verification note: calculation scope

The published Python arithmetic was checked locally using the stated fictional inputs. No drive, bench, throughput or wipe operation was tested. NIST SP 800-88 Rev. 2 keeps operation-outcome review and acceptance separate from planning. A schedule or bandwidth estimate cannot substitute for an accepted sanitization result.

Resale and evidence checklist

Keep one treatment record per physical asset even when several jobs share a station. Capacity reports describe work flow; release records identify which devices completed the approved procedure and which remain exceptions. Track failed jobs and rework without counting them as additional accepted assets.

What not to publish

Keep customer asset identifiers, queue contents, internal layouts and raw operational logs restricted. A public numerical example should use explicitly fictional values rather than silently presenting an unverified station benchmark.

Common mistakes

Avoid multiplying a one-drive speed by bay count after the shared resource saturates, treating a lower bound as an ETA, and confusing payload throughput with line rate. Also avoid applying the formula to crypto erase, or using a percentage of sampled readable data as a physical coverage claim.

CliDeck workflow fit

A runbook can retain assumptions, measured context, per-asset outcomes and exception decisions together. This proposed planning model does not claim a CliDeck benchmark, scheduler feature, supported device count or wiping-software release capability.

FAQ

Will more bays always reduce completion time?

No. More bays reduce one constraint; they do not enlarge a saturated shared resource or eliminate per-job work.

Is the calculated bound a promised finish time?

No. It is conditional resource accounting. Real scheduling and omitted work can increase the duration substantially.

Does the model prove queue stability?

No. Its arrival-rate check supplies necessary resource headroom conditions under simplified assumptions, not a waiting-time distribution or a sufficiency theorem.

Related guides

See the single-drive time model, failed-drive exceptions, and scope accounting limits.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

• Purpose
• When to use it
• When not to use it
• Target system or device
• Access path
• Read-only checks
• Change steps
• Expected output
• Stop conditions
• Rollback steps
• Verification steps
• Handoff notes
• Final summary format