3 votes

Android du et df très différents : Système de fichiers corrompu ?

Sur un décodeur Android Nougat (7.1.1), du y df de mon /data sont très différentes :

$ adb shell du -sh /data
1.0G    /data
$ adb shell df -H /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/block/sda9  10G   10G  469M  96% /data

Je ne pense pas que d'autres éléments soient montés sous les /data :

$ adb shell mount | grep "\/data"
/dev/block/sda9 on /data type ext4 (rw,seclabel,nosuid,nodev,relatime,discard,noauto_da_alloc,data=ordered)
$ adb shell mount | grep "sda9"
/dev/block/sda9 on /data type ext4 (rw,seclabel,nosuid,nodev,relatime,discard,noauto_da_alloc,data=ordered)

lsof m'indique qu'il existe des dizaines de processus contenant des centaines de petits fichiers supprimés du type

init          1       root    3w      CHR               1,11       0t0      14517 /dev/__kmsg__ (deleted)
ueventd     391       root    3w      CHR               1,11       0t0      14593 /dev/__kmsg__ (deleted)
  . . .
main        756       root  mem   unknown                                         /dev/ashmem/dalvik-large object space allocation (deleted)
main        756       root  mem   unknown                                         /dev/ashmem/dalvik-large object space allocation (deleted)
  . . .
omm.times  3934     system  mem   unknown                                         /dev/ashmem/dalvik-mark sweep sweep array free buffer (deleted)
omm.times  3934     system  mem   unknown                                         /dev/ashmem/dalvik-mark sweep sweep array free buffer (deleted)

L'utilisation busybox Les résultats sont différents ( df montre une utilisation beaucoup plus faible), mais il y a toujours un écart important entre les deux systèmes. du y df :

$ adb shell busybox du -sh /data
389.4M  /data
$ adb shell busybox df -h /data
Filesystem                Size      Used Available Use% Mounted on
/dev/block/bootdevice/by-name/userdata
                          9.7G      8.6G      1.1G  89% /data

Et en utilisant toybox les résultats sont similaires à busybox :

$ adb shell toybox du -sh /data
389M    /data
$ adb shell toybox df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/block/sda9  10G  8.6G  1.1G  89% /data

Il est important de noter que ces chiffres restent similaires après un redémarrage .

Par ailleurs, je tiens à signaler que je ne peux pas effectuer de mise à jour OTA de l'Android de cet appareil en raison d'un manque d'espace disque, même si l'image OTA ne pèse qu'environ 1 Go. Ce fait m'amène à penser que les résultats de l'étude de df sont exacts en termes d'espace disque réellement disponible.

Toutes les commandes adb sont exécutées en tant que Root, c'est-à-dire que j'ai fait adb root avant de les exécuter. Mais au risque de rendre cette question trop verbeuse, voici tout ce qui est exécuté à l'invite adb :

$ adb shell
Z:/ # whoami
root
Z:/ # du -sh /data
389M    /data
Z:/ # df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/block/sda9  10G  8.6G  1.1G  89% /data
10.197.12.14:/ # busybox du -sh /data
389.4M  /data
Z:/ # busybox df -h /data
Filesystem                Size      Used Available Use% Mounted on
/dev/block/bootdevice/by-name/userdata
                          9.7G      8.6G      1.1G  89% /data
Z:/ # toybox du -sh /data
389M    /data
Z:/ # toybox df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/block/sda9  10G  8.6G  1.1G  89% /data
Z:/ # 

Un utilisateur dans les commentaires a demandé ce qui suit :

Z:/ # while read num; do (( sum += num )); done <<< $(find /data -type f -exec stat -c%b {} +); expr $sum / 2048
393

Je comprends que du signale de l'espace libre en analysant les nœuds accessibles, ce qui pourrait signifier que mon système de fichiers est corrompu. Cependant, malheureusement, il s'agit d'appareils sur le terrain, et je ne veux pas avoir à (et ne pense pas pouvoir) exécuter fsck o e2fsck .

Qu'est-ce qui peut expliquer l'énorme différence entre du y df sur ce dispositif, et comment ce problème peut-il être résolu ? Je me ferai un plaisir de vous fournir d'autres journaux.

2voto

Milner Points 533

df signifie "Disk Free" (disque libre). Cela signifie qu'il suffit de vérifier l'espace libre (accessible à tous les utilisateurs) dans les "informations globales sur le système de fichiers". La taille du système de fichiers lui-même est également "globalement disponible". La différence est logiquement l'"espace utilisé". C'est fait.

du fonctionne différemment : non pas au niveau du système de fichiers, mais au niveau du fichier. Il doit rechercher chaque répertoire et chaque fichier séparément, déterminer leur taille et faire la somme. Il ne peut donc prendre en compte que ce à quoi il a accès.

Vous avez exécuté les deux commandes en tant qu'"utilisateur normal" - qui n'a pas le droit de traverser, par exemple. /data/data (où sont stockées toutes les données des applications). Il ne peut donc résumer qu'une partie de l'espace occupé sur le disque dur. /data . Pourriez-vous exécuter les deux commandes en tant qu'utilisateur root (comme la capture d'écran dans le commentaire de alecxs ), les chiffres seraient beaucoup plus proches les uns des autres - car en général, Root peut accéder à tous les fichiers. Cependant, comme le souligne à nouveau Alex à juste titre, il y a toujours un problème d'accès à l'information. SELinux qui pourrait refuser l'accès complet - ce qui, selon lui, est un problème connu pour les mtk-su sur l'Amazon FireTV stick, et pourrait être le coupable ici, et le montage isolé espaces nominatifs pourrait être une autre raison pour laquelle les fichiers sont invisibles.

TL;DR : il n'y a pas de corruption du système de fichiers, ni de panne de l'ordinateur. du binaire est nécessairement à l'origine de la différence. Tout peut fonctionner comme prévu. Si vous voulez vous en assurer, vous pouvez lancer fsck (si vous préférez, en mode lecture seule) pour exclure la première hypothèse - et mettre en place un cas de test à un autre endroit pour la seconde.

1voto

zippy Points 41

La partition /data était effectivement corrompue.

Après l'exécution e2fsck -p /dev/block/sda9 Voici la mise à jour du y df (encore une fois, après avoir fait un adb root ) :

$ adb shell du -s /data
1.3G    /data
$ adb shell df -H /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/block/sda9  10G  1.5G  8.9G  15% /data

Après avoir corrigé le système de fichiers, l'appareil a fonctionné correctement et a été mis à jour avec succès par la suite.

(Notez que j'ai constaté que je devais lancer e2fsck avec le -p il ne s'exécutait pas de manière interactive pour une raison quelconque).

Une partie des résultats de l'opération ci-dessus e2fsck est

data contains a file system with errors, check forced.
data: Deleted inode 163845 has zero dtime.  FIXED.
data: Deleted inode 163847 has zero dtime.  FIXED.
data: Deleted inode 163849 has zero dtime.  FIXED.
   . . . [snip ] . . .
data: Deleted inode 213003 has zero dtime.  FIXED.
data: Deleted inode 262223 has zero dtime.  FIXED.
data: Deleted inode 303108 has zero dtime.  FIXED.
data: 5203/655360 files (2.0% non-contiguous), 186831/2621440 blocks

Il y avait au total 140 lignes de ce type data: Deleted inode...

À titre d'information, nous pensons que ce problème est peut-être dû au fait que le système de fichiers a été saturé par les journaux, ce qui a entraîné une corruption lors de la prochaine tentative de téléchargement des mises à jour OTA : Ces téléchargements ont échoué, mais ont ensuite laissé le système de fichiers dans un état corrompu. Les tentatives de téléchargement suivantes ont semblé corrompre davantage le système de fichiers.

Merci beaucoup à @alecxs pour sa persévérance et ses détails pertinents. (Cependant, veuillez noter que pour exécuter e2fsck la partition /dev/block/sda9 a dû être démontée).

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X