Estoy considerando una aplicación donde está instalado un BeagleBone Black, preferiblemente ejecutando una de las imágenes de Debian recomendadas cargadas en eMMC, Por una fuente de 5V que se puede eliminar en cualquier momento. Quiero evitar la pérdida catastrófica de datos en este evento, incluso si se está realizando una escritura en un archivo. Al menos, quiero que el BBB aún pueda reiniciarse desde eMMC al devolver la energía, reparar el sistema de archivos (probablemente ext4) y ejecutar mi aplicación. Si puedo tener el seguro de que cualquier archivo que se haya limpiado correctamente es consistente, es ideal.
El problema que temo es que, cuando se pierde la energía mientras se está escribiendo en el eMMC, podría haber pérdida de datos en un sector impredecible, porque una nueva escritura del sector manejada por el eMMC provocó un borrado de la página Flash, y otros sectores en esa página se pierden, y (debido a la nivelación del desgaste y la reasignación del sector interna del eMMC) pertenecen a archivos o volúmenes que no se han escrito recientemente, incluso en sistemas o archivos de solo lectura. Ese problema se menciona aquí :
un ciclo de energía en el momento equivocado puede destruir datos en cualquier lugar de la tarjeta (SD o eMMC), sin importar dónde piense que esté escribiendo
y eso podría justificar la advertencia en el manual de BBB y aquí that
[apagar con el botón de encendido] también ayudará a evitar la contaminación de la tarjeta SD o del eMMC.
también en la tersa advertencia hecha por qué parece ser la principal fuente de eMMC para el BBB
Evite el apagado durante las operaciones de ESCRIBIR y BORRAR.
¿Hasta qué punto puede ocurrir tal pérdida de datos? ¿Cuál es la duración de la ventana de vulnerabilidad, si existe?
¿Hay soluciones estándar? Recomendaciones?
¿Existe algún mecanismo de software integrado contra esto y cómo funciona? En particular, es el TPS65217C programado para generar un NMI en caso de pérdida de VDD_5V, también conocido como AC, como lo permite el hardware, ¿y se maneja de una manera que detiene la actividad de escritura de eMMC en curso? Si no, ¿cómo puedo al menos agregar eso?
¿Detener cualquier actividad relacionada con eMMC es lo suficientemente bueno como para que el eMMC ingrese a un estado seguro por sí mismo después de algún retraso? ¿Qué retraso?
¿Qué pasa con un capacitor o Supercap (como Murata DMT3N4R2U224M3DTA0: 0.22F, 4.2V, 0.3 & ohm;) en el conector de la batería para proporcionar cierta reserva de energía?
¿Hay modos / configuraciones en el eMMC para configurar un compromiso de seguridad / rendimiento de escritura? ¿Cuáles son los valores predeterminados, son ajustables?
Actualización importante: he localizado información autorizada en la especificación de eMMC de marzo de 2010 acerca de la confiabilidad cuando se pierde el poder durante la escritura:
En general, una interrupción en un proceso de escritura no debe causar daños en los datos existentes en ninguna otra dirección. Sin embargo, el riesgo de que se elimine la energía durante una operación de escritura es diferente en diferentes aplicaciones. Además, para algunas tecnologías utilizadas para implementar eMMC, existe un compromiso entre la protección de los datos existentes (por ejemplo, los datos escritos por las operaciones de escritura completadas anteriormente), durante un fallo de alimentación y el rendimiento de escritura.
Sigue una gran cantidad de información valiosa en esa fuente, incluida la descripción de cómo el eMMC declara que promete (o no) proteger los datos escritos previamente contra el borrado al azar en caso de pérdida de energía, y lo que parecen ser áreas verdaderamente protegidas contra escritura. .
Adición: un comentario menciona que los teléfonos móviles utilizan sistemas de archivos de solo lectura en eMMC, y son No se sabe que experimenten corrupción de eso. Sin embargo, los teléfonos móviles tienen una batería grande, y eso prácticamente garantiza que no experimenten una pérdida abrupta de energía en el funcionamiento normal, por lo que no me preocupa el mecanismo de corrupción de eMMC que temo.
