Est-ce qu'Android 8 a activé la journalisation dans son ext4 système de fichiers ?
Cela dépend de plusieurs facteurs. Les équipementiers peuvent éventuellement désactiver la journalisation, par exemple dans les cas suivants system comme elle est toujours censée être utilisée R/O. De nos jours, les ext4 y f2fs sont des systèmes de fichiers couramment utilisés sur Android. ext4 sur userdata partition. f2fs est d'origine a log-structured qui est un système de fichiers circular buffer c'est ce qu'est un journal, mais la fonctionnalité est différente.
Les systèmes de fichiers font partie du noyau Linux, et non d'Android (AOSP) lui-même. ext4 est créé par défaut avec journal, bien qu'il dépende de mke2fs.conf et peut être désactivé à l'aide de la touche mke2fs o tune2fs option -O ^has_journal . La prise en charge de la journalisation peut être vérifiée à partir des caractéristiques du système de fichiers en exécutant tune2fs -l /dev/block/bootdevice/by-name/userdata | grep has_journal (ou utiliser dm-0 le dispositif de blocage si userdata (FDE), mais elle nécessite l'utilisation de Root. Comme alternative si mount | grep 'on /data' spectacles data={journal|ordered|writeback} alors le journal est activé à coup sûr.
Fait sdcardfs reconnaître les ext4 système de fichiers et journalisation ?
sdcardfs lui-même n'a pas de journal, mais comme le système de fichiers émulé est superposé à /data/media (qui est ext4 ), les fichiers créés par sdcardfs sont enregistrées dans le journal du système de fichiers sous-jacent.
Sous Android 8, il n'est pas évident de savoir comment la fonction journaling peut-elle être utilisée pour récupérer des données ?
Oui, certainement, si vous avez déjà Root et que les données ne sont pas écrasées. Nous avons des outils comme extundelete qui sont très efficaces. Mais il faut tenir compte de facteurs tels que TRIM et d'autres décrits ci-dessous et dans les liens indiqués.
Les nouvelles données sont-elles écrites dans de nouvelles zones vides ou les zones supprimées sont-elles d'abord utilisées ?
C'est une autre question, qui n'a rien à voir avec Android. La question est la suivante fréquence à laquelle un système de fichiers écrase les blocs de données supprimés et la réponse n'est pas simple. Créer un nouveau ext4 créer un fichier foo à l'intérieur et le supprimer. Créer un nouveau fichier bar et il prendra le bloc d'inode et les blocs de données libérés par foo . Supprimer bar et créer un fichier baz il occupera le même espace. Cependant, dans la réalité, les choses sont plus compliquées. Les blocs de données du fichier supprimé seront-ils immédiatement écrasés ou non ? Cela dépend de la taille du nouveau fichier, de la fragmentation du système de fichiers, du nombre de LBA libres avant l'emplacement logique du fichier supprimé, etc.
PS :
Les choses sont différentes sur f2fs , c'est le F cil F convivial F ile S Le système de gestion de l'usure, par conséquent, écrit de préférence les données dans de nouveaux blocs vides (segments libres), de manière à ce que le système de gestion de l'usure soit le plus performant possible. FTL n'a pas besoin d'effacer des cellules, en essayant de réduire le nombre de E/P sur la mémoire flash. Plus tard, il effectue une collecte de déchets en arrière-plan synchronisée avec la FTL pour libérer les LBA correspondant aux données supprimées. Mais les outils tels que debugfs ne sont pas facilement disponibles pour les f2fs pour explorer les inodes supprimés et rechercher les blocs de données correspondants à partir de journal . Ainsi, du point de vue de la récupération des données, f2fs n'est pas très amicale (AFAIK et expérience).
RELATED : Pourquoi la récupération des données supprimées est-elle difficile / impossible ?
