¿Cuándo está listo el almacenamiento tras el encendido? Mida hasta la recuperación de la aplicación

Una unidad puede aparecer en el menú del firmware o en la lista de dispositivos del sistema operativo antes de que la aplicación pueda utilizar sus datos. El descubrimiento del dispositivo dice muy poco sobre la primera lectura correcta, el montaje del volumen o la recuperación de una base de datos local. Para un OEM, el valor relevante suele ser el tiempo transcurrido desde un evento definido de encendido o reinicio hasta una función de negocio correcta.

Esta guía establece un reloj de referencia común para los equipos de almacenamiento y de aplicaciones. Los hitos se aplican a diferentes interfaces, pero los comandos y registros deben adaptarse al host real SATA, NVMe, eMMC, UFS o de medios extraíbles. Ningún estándar de interfaz proporciona un requisito universal de «servicio listo en X segundos».

Definir los eventos de inicio y fin

Elija un evento de inicio físico o lógico: por ejemplo, una transición medida en la alimentación del dispositivo, la desactivación de una señal de reinicio (reset) o un comando de reinicio iniciado por el host. Documente el umbral y el punto de observación del diseño de destino. Inicie una línea temporal monotónica en dicho evento. Si la única marca de tiempo disponible proviene del registro de arranque de Linux, especifique dónde comienza su reloj; es posible que omita el tiempo previo de alimentación y firmware.

Elija un evento final que el usuario del dispositivo pueda reconocer. «Proceso de aplicación iniciado» puede ser demasiado prematuro si el proceso debe abrir una base de datos, recuperar una cola o aceptar un comando de grabación. Defina una transacción de comprobación de estado pequeña y repetible que ejercite la ruta de almacenamiento prevista. Conserve su entrada y el resultado correcto en el registro de prueba.

El systemd-analyze manual explica que la medición del arranque puede detenerse cuando los servicios se han generado sin demostrar que hayan finalizado su inicialización o que el disco esté inactivo. Utilice los tiempos del sistema operativo como una traza, no como el resultado de aceptación de la aplicación.

Marcar cada transición en una sola línea temporal

Algunos sistemas realizan una escritura antes del montaje; otros utilizan medios de solo lectura o prohíben escrituras de prueba durante el arranque normal. Adapte T3 y T4 al diseño real y registre un marcador omitido en lugar de asumir que se superó. NVM Express documenta la identidad de los espacios de nombres y el herramientas de gestión y consulta de registros para dispositivos NVMe; esto puede ayudar a capturar T1 y diagnosticar errores. No obstante, no miden T5 para la aplicación OEM.

Informe los intervalos transcurridos desde T0, además del estado en el que se detuvo una ejecución. Si los relojes de la traza eléctrica y del registro de software difieren, agregue un disparador común o documente la incertidumbre de alineación. Dos eventos con marcas de tiempo de relojes no sincronizados no se pueden ordenar de forma fiable.

Probar los estados a los que se enfrentará el dispositivo desplegado

El caso más sencillo es una unidad nueva tras un apagado ordenado. Un plan de pruebas útil también cubre el reinicio en caliente del dispositivo de destino, tiempos breves de apagado, el nivel de llenado de la aplicación y la recuperación tras una interrupción cuando ese escenario esté contemplado. Defina la placa host, el firmware, el modelo/capacidad/firmware del medio, el sistema de archivos, el controlador, los parámetros de reintento y la secuencia de alimentación para cada ejecución. Mantenga diferenciadas las unidades y los lotes de producción.

Interrumpir la alimentación durante una escritura puede forzar al sistema de archivos o a la aplicación a una ruta de recuperación. Esta prueba de temporización evalúa cuándo el sistema vuelve a ser utilizable; una cualificación de pérdida de alimentación independiente evalúa qué datos deben sobrevivir. No considere que un arranque completado sea una prueba de integridad de datos. A la inversa, no califique un retraso legítimo de recuperación como un defecto a menos que infrinja los requisitos especificados del dispositivo.

Ejecute suficientes dispositivos y ciclos independientes en función del riesgo del proyecto. Conserve todos los tiempos completados, tiempos de espera agotados, reintentos, reinicios y estados imprevistos de solo lectura. Un intento fallido seguido de un reintento automático debe figurar en el resultado, incluso si la aplicación finalmente responde.

Mantener un registro que permita explicar una ejecución lenta

Antes de realizar las pruebas, establezca si la aceptación utiliza un límite máximo por ejecución, un percentil, un límite en la tasa de fallos o una combinación de ellos. Los percentiles obtenidos de una muestra pequeña no deben considerarse garantías estables de cola extrema. Indique el tamaño de muestra y el recuento de unidades junto a cualquier estadística; los ciclos repetidos en una sola unidad no representan la variación entre distintas unidades o lotes. Registre los tiempos de espera agotados como fallos u observaciones censuradas, no como tiempos completados equivalentes al límite del tiempo de espera.

Si T1 se retrasa, investigue la alimentación, el reinicio y el establecimiento del enlace. Si T1 es puntual pero T2 falla, conserve los primeros errores del host y del dispositivo. Si T3 tiene éxito pero T5 se retrasa, inspeccione la inicialización y la recuperación de la aplicación antes de culpar a la velocidad del almacenamiento. El primer límite que no cumpla su requisito guiará el siguiente experimento.

Para una solicitud de cotización, proporcione la configuración del host de destino, la identidad requerida del medio, las definiciones de inicio/fin y los resultados observados. Estos son datos de entrada para la aceptación del proyecto; una cifra de velocidad de catálogo no puede sustituir a un plazo de servicio medido de T0 a T5.