When Is Storage Ready After Power-On? Measure Through Application Recovery

A drive may appear in a firmware menu or operating-system device list before the application can use its data. Device discovery says little about the first successful read, volume mount or recovery of a local database. For an OEM, the relevant number is usually the elapsed time from a defined power or reset event to a successful business function.

This guide creates a common clock for storage and application teams. The milestones apply to different interfaces, but the commands and logs must be adapted to the actual SATA, NVMe, eMMC, UFS or removable-media host. No interface standard supplies a universal “service ready within X seconds” requirement.

Define the start and end events

Choose one physical or logical start event: for example, a measured device supply transition, deasserted reset signal or host-initiated restart command. Document the threshold and observation point from the target design. Start a monotonic timeline at that event. If the only available timestamp is a Linux boot log, say where its clock begins; it may omit earlier power and firmware time.

Choose an end event the user of the device would recognize. “Application process started” may be too early if the process must open a database, recover a queue or accept a recording command. Define one small, repeatable health transaction that exercises the intended storage path. Keep its input and success result in the test record.

The systemd-analyze manual explains that boot timing can stop when services have been spawned without proving that they finished initialization or the disk is idle. Use OS timing as one trace, not as the application acceptance result.

Mark each transition on one timeline

Some systems perform a write before a mount; others have read-only media or prohibit test writes during normal boot. Adapt T3 and T4 to the real design, and record an omitted marker rather than pretending it passed. NVM Express documents namespace identity and management/log access for NVMe devices; these can help capture T1 and diagnose errors. They do not measure T5 for the OEM application.

Report elapsed intervals from T0, plus the state where a run stopped. If the clocks for the electrical trace and software log differ, add a common trigger or document alignment uncertainty. Two events with timestamps from unsynchronized clocks cannot be ordered reliably.

Test the states the deployed device will encounter

The easiest case is a fresh unit after an orderly shutdown. A useful test plan also covers the target device's warm restart, short off-time, application fill level and recovery after an interruption where that event is in scope. Define the host board, firmware, media model/capacity/firmware, filesystem, driver, retry settings and power sequence for every run. Keep units and production lots distinguishable.

Interrupting power during a write can put the filesystem or application into a recovery path. This timing test asks when the system becomes usable; a separate power-loss qualification asks which data must survive. Do not call a completed boot proof of data integrity. Conversely, do not call a legitimate recovery delay a defect unless it violates the written device requirement.

Run enough independent devices and cycles for the project risk. Retain every completed time, timeout, retry, reset and unexpected read-only state. A failed attempt followed by an automatic retry belongs in the result even when the application eventually responds.

Keep a record that makes a slow run explainable

Before testing, state whether acceptance uses a per-run maximum, a percentile, a failure-rate limit, or a combination. Percentiles from a small sample should not be treated as stable extreme-tail guarantees. Report sample count and unit count beside any statistic; repeated cycles on one unit do not represent variation among units or lots. Keep timeouts as failures or censored observations, not completed times equal to the timeout limit.

If T1 is late, investigate power, reset and link setup. If T1 is prompt but T2 fails, preserve the first host and device errors. If T3 succeeds but T5 is late, inspect application initialization and recovery before blaming storage speed. The first boundary that misses its requirement guides the next experiment.

For a quote request, provide the target-host configuration, required media identity, start/end definitions and observed results. These are project acceptance inputs; a catalog speed number cannot substitute for a measured T0-to-T5 service deadline.