Caché eMMC, flush y Reliable Write: recuperación tras cortes

Un controlador embebido guarda una configuración, recibe éxito y pierde energía 20 milisegundos después. En el siguiente arranque el registro no existe. La acusación inmediata suele ser “eMMC defectuoso”, aunque quizá los datos nunca cruzaron el límite de persistencia que suponía el software.

Entre el búfer de la aplicación y las celdas NAND hay colas, cachés y actualizaciones de metadatos. La ingeniería de recuperación empieza por nombrar cada límite y demostrar que el orden previsto llega a la configuración eMMC exacta de producción.

“Escritura completa” tiene varios significados

Una ruta simplificada contiene al menos cinco etapas:

1. Aplicación y runtime. Los datos pueden permanecer en un búfer del proceso o biblioteca.
2. Sistema de archivos y caché de página. El kernel puede aceptar la escritura antes de enviar páginas sucias o journal al bloque.
3. Capa de bloques y driver. Las solicitudes pueden combinarse, reordenarse o esperar.
4. Controlador eMMC y caché opcional. El dispositivo administrado puede reconocer datos aún volátiles según funciones y comandos activos.
5. FTL y NAND. Datos, mapas y corrección de errores deben quedar consistentes en flash.

El éxito de write() normalmente significa que el sistema operativo aceptó los bytes, no que estén programados en medio no volátil. fsync() solicita un límite más fuerte, pero su resultado depende de todas las capas posteriores.

Exprese el requisito de modo observable. “Configuración confirmada” puede significar que, tras retirar energía en cualquier instante posterior, el equipo arranca, selecciona el registro antiguo completo o el nuevo completo y nunca acepta uno dividido o con checksum inválido. Eso se puede probar; “el eMMC no debe corromperse” no.

Flush y FUA definen orden, no magia

La documentación de bloques de Linux separa dos mecanismos. Un pre-flush exige que escrituras anteriores alcancen almacenamiento no volátil antes de continuar. Force Unit Access, representado por REQ_FUA, exige que la escritura asociada finalice después de persistir [1]. Sistemas de archivos y drivers pueden combinar o emular operaciones según el soporte.

Así un journal o diseño copy-on-write puede ordenar:

escribir datos nuevos
  -> persistir datos
  -> escribir marcador
  -> persistir marcador

Tras la interrupción, la recuperación acepta el estado nuevo solo si marcador y datos son válidos. El dispositivo no puede deducir por sí mismo esta transacción de aplicación.

Desactivar barreras o flushes para un benchmark puede invalidar la recuperación. La documentación F2FS describe barrier, nobarrier y flush_merge como controles explícitos de orden y tratamiento de flush [3]. Un resultado obtenido con persistencia debilitada no equivale a la configuración de producción.

La caché eMMC es una configuración

La flash administrada puede exponer caché de escritura opcional, cuyo estado se representa en Extended CSD. mmc-utils en Linux lee y analiza EXT_CSD, activa o desactiva caché cuando hay soporte, configura operaciones de fondo y controla fiabilidad de escritura por partición [2]. Por eso el estado de registros forma parte de la especificación del producto.

La caché mejora respuesta y absorbe ráfagas, pero puede abrir un intervalo donde datos reconocidos aún no llegaron a NAND. La decisión correcta no es “caché activa insegura” ni “caché inactiva segura”. Desactivarla puede elevar latencia y reducir rendimiento, mientras permanecen cachés del host, transacciones incompletas, actualizaciones FTL y alimentación débil.

Registre parte exacta, firmware si se expone, revisión eMMC, tamaño y estado de caché y configuración de particiones. Vuelva a leerlos en muestras productivas. Una imagen de software dorada no garantiza la misma conducta si cambian almacenamiento o BOM.

Reliable Write cubre un contrato más estrecho

Reliable Write de eMMC busca mejorar atomicidad o fiabilidad de escrituras emitidas con el mecanismo definido. Granularidad, particiones elegibles y configuración dependen de revisión e implementación. Compruebe capacidad y estado en EXT_CSD y documentación del proveedor.

No lo convierta en la afirmación de que todos los datos sobreviven a cualquier corte. Separe tres categorías:

Un diseño recuperable suele usar registros dobles, secuencias crecientes, checksums y un marcador final. Reliable Write puede reforzar operaciones seleccionadas, pero el software necesita formato recuperable y orden explícito.

No es la misma pregunta que la PLP de hardware en un SSD

La protección de hardware ante pérdida de energía de un SSD pregunta si la energía almacenada y el firmware permiten terminar un trabajo interno definido cuando desaparece la entrada. Este artículo pregunta otra cosa: si la solicitud de persistencia de la aplicación llega al eMMC con el orden previsto y si la aplicación puede recuperar una transacción interrumpida.

Ambos temas coinciden en el límite de alimentación del sistema, pero no son equivalentes. Un diseño eMMC puede ser recuperable sin supercondensador cuando usa registros atómicos, orden verificado y recuperación ante interrupción arbitraria. A la inversa, un SSD con PLP de hardware no corrige una aplicación que escribe el marcador de commit antes de los datos. Para el límite centrado en el dispositivo, consulte la explicación de PLP para SSD.

Las operaciones de fondo y el FTL importan

El controlador realiza wear leveling, recolección de basura, retiro de bloques, ECC y mapas. Parte ocurre en primer plano; dispositivos compatibles exponen estado y control de Background Operations. BKOPS de eMMC explica por qué el mantenimiento afecta latencia y cómo el tiempo inactivo puede reducir trabajo urgente posterior.

Un corte durante gestión interna no equivale a uno durante lectura en reposo. Incluya escritura sostenida, llenado alto, borrado y reescritura, actividad BKOPS y transiciones alrededor de flushes. Conserve regiones de referencia antiguas para detectar daño colateral fuera del archivo actualizado.

La salud es otro eje. Estimaciones de vida y pre-EOL en EXT_CSD no predicen el instante exacto de fallo, pero separan resultados de muestra fresca y condición de desgaste definida. Consulte registros de salud eMMC y sus límites.

En la práctica, la alimentación participa en el protocolo

Ni el mejor orden de software compensa un colapso eléctrico indefinido. Mida los rieles cerca del encapsulado, no solo en la fuente de banco. Capture tensión, corriente y reset durante escritura, flush e interrupción.

Defina:

• tensión nominal y tolerancia;
• velocidad de caída y secuencia de rieles;
• umbral brownout y propagación de reset;
• hold-up desde detección hasta tensión mínima del eMMC;
• posibilidad de completar una acción final dentro de ese intervalo;
• rutas de realimentación mediante pines de E/S o periféricos.

Si se promete apagado ordenado, presupuestar desde detección, quietud de aplicación, sync, flush y retirada verificada. Use peor latencia medida, no promedio. Sin energía de reserva, diseñe para interrupción arbitraria y no suponga que habrá un flush final.

Protocolo reproducible de cortes

Use PCB, alimentación, bootloader, kernel, filesystem, aplicación y parte eMMC finales. Una placa de desarrollo con regulador o driver diferente aporta poca evidencia sobre producción.

1. Cree transacciones identificables

Escriba registros con secuencia, longitud, carga determinista y checksum. Mantenga dos o más ranuras para elegir el registro válido más reciente. Cree aparte una región estática con hashes conocidos.

2. Instrumente los límites

Marque escritura de aplicación, final de fsync, emisión y final de flush y telemetría disponible. Capture UART o logs del kernel fuera del dispositivo probado, para conservar evidencia aunque se dañe el sistema de archivos.

3. Interrumpa en puntos distribuidos

Use interruptor o fuente programable, no extracción manual del cable. Corte antes de datos, durante datos, entre datos y marcador, durante flush, justo después de la finalización reportada y con tráfico de fondo. Combine offsets deterministas y tiempos aleatorios.

4. Varíe las condiciones

Cubra medio nuevo y preacondicionado, llenado bajo/alto, reposo/carga sostenida, frío/ambiente/calor, caché activa/inactiva cuando corresponda y caídas rápidas/lentas. Elija el número de ciclos desde la probabilidad máxima tolerable y el nivel de confianza, y distribuya los ciclos por la matriz en vez de repetir una sola condición cómoda.

5. Clasifique cada recuperación

Después de cada arranque registre éxito, montaje o reparación, secuencia elegida, checksum, hashes estáticos, errores del kernel y tiempo de retorno. Preserve medios fallidos para análisis en vez de reformatear automáticamente.

dm-log-writes registra escrituras de bloque y límites flush/FUA, y permite reproducir muchos puntos de fallo [4]. Es útil para desarrollar filesystem y software. Aun así se requiere corte físico: la reproducción no imita el colapso del regulador ni el tiempo interno del eMMC.

Cuantifique qué significa observar cero fallas

Para n ensayos Bernoulli independientes con cero fallas, el límite superior unilateral al 95% de la probabilidad de falla por ensayo es:

p_superior = 1 - 0.05^(1/n)

El cálculo no demuestra que los cortes sean independientes. Interrumpir siempre en el mismo desplazamiento puede repetir casi el mismo estado del controlador y exagerar la cobertura. Informe el límite estadístico y también la distribución por fase de transacción, carga, temperatura, llenado, desgaste y perfil de caída de tensión.

Defina aprobación antes de probar

No agrupe todo como “corrupción”. Perder el último registro, no montar, alterar datos antiguos o inutilizar el dispositivo apuntan a mecanismos diferentes.

Evidencia de compra y control de cambios

Solicite parte, capacidad, revisión eMMC, soporte de caché y Reliable Write, estado EXT_CSD predeterminado y programado, política de firmware/cambios, temperatura, resistencia y guía del proveedor. Los recursos técnicos públicos son un inicio; la evidencia final debe corresponder al SKU cotizado [5].

La inspección de entrada debe leer identidad y configuración y conservarlas por lote. El manejo mecánico también cuenta: un BGA eléctricamente calificado puede dañarse por humedad o reflow deficientes; incluya almacenamiento, horneado y reflow en el plan de calificación de flash.

Para una revisión OEM con Kalstor, entregue árbol de alimentación, software, filesystem y opciones de montaje, transacción, perfil de interrupción, temperatura y criterios. El flujo de calificación OEM vincula identidad de muestra y evidencia.

Conclusión

La recuperación tras pérdida de energía es una propiedad del sistema. Transacciones, orden del filesystem, flush, driver, caché eMMC, Reliable Write, FTL y caída de tensión participan. Defina el límite de persistencia, lea la configuración real e interrumpa el producto final en muchos puntos controlados. Así “la escritura terminó” se convierte en una afirmación demostrada.