Ensayo de pérdida de energía para calificar SSD OEM

“Protección ante pérdida de energía” no es un requisito completo. Puede referirse a la protección de tablas de mapeo del controlador, de datos ya confirmados al host, de datos cubiertos por un Flush completado o de un subconjunto definido por la implementación. Una prueba que no identifique ese límite puede acumular muchos cortes y poca evidencia útil.

La finalidad de la calificación OEM no es demostrar que un SSD vuelve a arrancar después de quitarle alimentación. Es determinar, para un dispositivo y una configuración de host exactos, qué estado sigue siendo válido tras una pérdida no controlada y si coincide con la declaración escrita del proveedor.

Este protocolo es aplicable a programas SATA y NVMe. Los comandos difieren por interfaz; el procedimiento final debe seguir la especificación aplicable y la documentación del dispositivo.

Defina la declaración de protección antes del ensayo

Empiece por resultados observables, no por nombres de componentes.

La especificación de Open Compute Project resulta útil porque separa la conducta ante apagado abrupto de la supervisión de salud PLP y, para dispositivos que declaran ese perfil, exige más que comprobar si el condensador está abierto o en corto [1]. Sus requisitos no se aplican automáticamente a todo SSD industrial o cliente. Sirven para redactar una especificación de compra explícita; no prueban que una unidad no ensayada cumpla.

Solicite al proveedor que declare:

• si existe caché de escritura volátil y cómo se informa;
• qué datos se prometen durables tras completar comando, Flush o FUA;
• si se protegen datos de usuario y metadatos de la capa de traducción flash;
• perfil admitido de retirada de alimentación y tiempo mínimo de caída de tensión;
• límites de recuperación y conducta tras un fallo del circuito PLP;
• modelos, capacidades, revisión de controlador y firmware cubiertos.

Sin esos límites, “PLP” no puede convertirse en criterio de aceptación.

Congele el objeto de ensayo y la ruta del host

La unidad de calificación es la configuración, no el nombre de familia.

NVMe define el estado de apagado del controlador y la semántica de comandos, pero no hace que todas las plataformas retiren alimentación de igual forma [2]. Un relé colocado muy aguas arriba puede descargar a través de la capacitancia del sistema durante mucho más tiempo que el fallo de campo. Mida la tensión en el conector del dispositivo y conserve la forma de onda de cortes representativos.

Use un dispositivo dedicado que pueda interrumpir la alimentación del SSD de forma independiente cuando la arquitectura lo permita. Un reinicio por software, reset del controlador o apagado ordenado ejercita otro estado y no debe informarse como corte abrupto.

Establezca un oráculo de datos

Tras reiniciar, el laboratorio debe distinguir datos antiguos válidos, datos nuevos válidos y corrupción. Listar directorios o ejecutar una revisión del filesystem es demasiado general.

Un generador práctico escribe registros con:

• LBA u offset objetivo;
• secuencia monotónica;
• identificador de ejecución y ciclo;
• hash o checksum de la carga;
• patrón conocido independiente de los metadatos.

Mantenga el flujo esperado en un sistema protegido separado. Clasifique cada comando por su posición respecto a la finalización y al límite durable:

1. Conjunto durable: escrituras que el protocolo y la declaración obligan a conservar.
2. Conjunto indeterminado: escrituras emitidas que aún no habían cruzado ese límite.
3. Conjunto intacto: direcciones no modificadas durante el ciclo.

Cada registro durable debe coincidir. Un registro indeterminado puede resolverse como versión antigua o nueva válida si el contrato lo permite, pero dañar otra dirección no es un efecto aceptable de caché. Así se evita clasificar toda pérdida reciente como fallo sin dejar pasar corrupción silenciosa fuera de la transacción interrumpida.

Si el producto incluye filesystem o base de datos, realice dos capas. Primero pruebe bloques sin procesar para aislar el SSD. Después pruebe el stack de aplicación para evaluar si Flush, barreras y recuperación utilizan correctamente el contrato del dispositivo.

Construya una matriz que exponga fallos dependientes del estado

Un punto de corte bajo una carga secuencial es una demostración, no una calificación.

Preacondicione el SSD al estado relevante. Probar solo una unidad nueva y vacía puede evitar garbage collection, presión de mapeo y trabajo en segundo plano: precisamente los estados que pueden interactuar con la interrupción.

Aleatorice el corte dentro de ventanas definidas. Conserve la semilla y el rastro de comandos emitidos y completados para reconstruir la secuencia.

Ejecute un ciclo controlado

1. Capture identidad electrónica, salud, errores y estado inicial del namespace.
2. Verifique el conjunto de datos base.
3. Inicie carga y diario externo de comandos.
4. Corte en el punto aleatorio seleccionado.
5. Registre tensión y corriente del dispositivo durante toda la caída.
6. Mantenga sin energía el intervalo especificado y restáurela sin cambiar el host inesperadamente.
7. Mida tiempo de enumeración y de disponibilidad estable de I/O.
8. Lea y clasifique conjuntos durable, indeterminado e intacto.
9. Capture de nuevo salud, errores y eventos antes de reparar o reintentar.

NVMe-CLI expone identidad, SMART/Health, errores y telemetría admitida [3][4]. Conserve salida sin procesar, versión, comando y hora. Una captura de un panel no basta porque no puede reinterpretarse al cambiar la hipótesis.

No permita reparación automática, actualización de firmware ni bucles de reinicio antes de recoger evidencia. Si no enumera, siga la recuperación predefinida y preserve el primer estado observado.

Escriba los criterios de fallo antes de probar

Un resultado debe identificar la capa. “La unidad sobrevivió” oculta la diferencia entre corrección de datos, recuperación del namespace y disponibilidad tardía.

Ante cualquier fallo, suspenda la secuencia, preserve registros e incorpore la unidad al proceso de evidencia RMA. Repetir de inmediato puede cambiar el estado persistente y reducir valor diagnóstico.

Trate la repetición como evidencia, no como certeza

Distribuya muestras entre lotes y revisiones materiales. Cortes repetidos en una unidad exploran tiempos y estados internos, pero no variación entre unidades. Muchas unidades expuestas a un solo instante tienen la limitación opuesta.

Si no hay fallos en n ensayos independientes, la “regla de tres” unilateral al 95% sitúa aproximadamente la probabilidad por debajo de 3/n. Los cortes en el mismo SSD rara vez son independientes; ese valor es, como máximo, una orientación optimista. Informe por separado unidades, ciclos, estratos y exposición.

La calificación respalda la configuración ensayada. Cambios de firmware, controlador, NAND, capacidad, circuito PLP o caché del host deben entrar al proceso PCN y de recalificación.

Convierta el resultado en control de compra

El paquete final debe contener:

• declaración escrita de PLP y caché;
• número de parte, límite BOM y firmware calificados;
• forma de onda y descripción del dispositivo de corte;
• generador, oráculo y versiones de software;
• manifiesto de muestras y lotes;
• matriz, ciclos y diagnósticos sin procesar;
• criterios de aceptación y parada;
• procedimiento de análisis y recuperación;
• disparadores de recalificación y términos de aviso.

El plan general de calificación aporta el marco de muestra a producción. La explicación de PLP describe el mecanismo; este protocolo define cómo ensayar una declaración concreta.

La pregunta útil del RFQ no es “¿Tiene PLP?”. Es: ¿Qué escrituras y metadatos protege este SKU, bajo qué perfil eléctrico, con qué evidencia y dentro de qué límite de control de cambios? Incluya ese requisito en una consulta OEM para que la muestra propuesta pueda vincularse a un plan de aceptación verificable.