¿Android 8 tiene habilitado el diario en su ext4 ¿Sistema de archivos?
Depende de algunos factores. Los fabricantes de equipos originales pueden desactivar el registro en el diario, por ejemplo, en system partición como siempre se supone que se utiliza R/O. Hoy en día ext4 y f2fs son sistemas de archivos de uso común en Android, así que primero asegúrate de tener ext4 en userdata partición. f2fs es de origen a log-structured que es un sistema de archivos circular buffer Eso es lo que es un diario, pero la funcionalidad es diferente.
Los sistemas de archivos son parte del kernel de Linux, no de Android (AOSP). ext4 por defecto se crea con el diario, aunque depende de mke2fs.conf y se puede desactivar con mke2fs o tune2fs opción -O ^has_journal . El soporte de Journaling puede comprobarse desde las características del sistema de archivos ejecutando tune2fs -l /dev/block/bootdevice/by-name/userdata | grep has_journal (o utilizar dm-0 bloquea el dispositivo si userdata tiene FDE) pero requiere Root. Como alternativa si mount | grep 'on /data' muestra data={journal|ordered|writeback} entonces el diario está habilitado con seguridad.
En sdcardfs reconocer el ext4 ¿Sistema de archivos y journaling?
sdcardfs en sí no tiene un diario, pero como el sistema de archivos emulado se apila sobre /data/media (que es ext4 ), los archivos creados a través de sdcardfs se registran en el diario del sistema de archivos subyacente.
En Android 8 no está claro cómo el journaling funciona, por ejemplo, ¿puede utilizarse para recuperar datos?
Sí, definitivamente, si ya tienes Root y los datos no se sobrescriben. Tenemos herramientas como extundelete que son muy eficaces. Pero hay que tener en cuenta factores como TRIM y otros descritos a continuación y en los enlaces dados.
¿Los nuevos datos se escriben en áreas frescas vacías o primero se utilizan las áreas borradas?
Bueno esa es otra pregunta, de nuevo no tiene nada que ver con Android. La pregunta es la frecuencia con la que un sistema de archivos sobrescribe los bloques de datos borrados y no es sencillo de responder. Crear un nuevo ext4 sistema de archivos, crear un archivo foo dentro de él y borrarlo. Crear un nuevo archivo bar y tomará el bloque de inodo y los bloques de datos liberados por foo . Borrar bar y crear el archivo baz ocupará el mismo espacio. Sin embargo, en la realidad las cosas son complicadas. Si los bloques de datos del archivo eliminado se sobrescriben inmediatamente o no, depende del tamaño del nuevo archivo, de lo fragmentado que esté el sistema de archivos, de la cantidad de LBAs libres que tenga antes de la ubicación lógica del archivo eliminado, etc.
PS:
Las cosas son diferentes en f2fs Es el F pestaña F ágil F ile S ystem, por lo que, como estrategia de nivelación de desgaste, escribe preferentemente datos en nuevos bloques vacíos (segmentos libres), de modo que FTL no tiene que borrar celdas, tratando de reducir los recuentos de E/P en la memoria flash. Posteriormente, realiza una recolección de basura (GC) en segundo plano sincronizada con FTL para liberar los LBAs correspondientes a los datos borrados. Pero las herramientas como debugfs no están fácilmente disponibles para f2fs para explorar los inodos eliminados y buscar los bloques de datos correspondientes de journal . Así que desde el punto de vista de la recuperación de datos, f2fs no es muy amable (AFAIK y con experiencia).
RELACIONADO: ¿Qué hace que la recuperación de datos borrados sea difícil o imposible?
