Pourquoi, en particulier à partir d'Android 6 (pour la version 5 je ne sais pas, mais sûrement pas pour les 4.x et versions inférieures), y a-t-il une lenteur excessive pour des opérations triviales sur un dossier (par exemple, renommer un dossier ou coller son contenu) lorsqu'il contient de nombreux très petits fichiers?
Cela me semble être une dégradation tragique des performances du système. À quoi pensaient les programmeurs de Google lorsqu'ils ont conçu ces versions?
Ce problème est probablement causé par Android permettant l'accès au stockage interne via FUSE (Système de fichiers en Espace Utilisateur), car le stockage interne est lui-même juste un sous-répertoire de la partition /data.
Ces tests ont été réalisés sur LineageOS 14.1 (Android 7.1.2), via l'émulateur de terminal Termux, en utilisant un répertoire appelé test contenant 9414 fichiers dont la taille variait d'un à cinq octets. La partition /data sous-jacente était formatée en ext4.
Je ne suis affilié ni à Termux ni à son auteur.
Les commandes utilisées étaient
cd /sdcard
time cp -r test test2Cela a renvoyé un temps écoulé de
réel 1m10.477s
utilisateur 0m0.595s
système 0m3.360sLe répertoire test2 a été supprimé après avoir confirmé les résultats.
Les commandes utilisées étaient
su
cd /data/media/0
time cp -r test test2Fondamentalement, ce que j'ai fait ici était de me déplacer vers le sous-répertoire /data qui contient le stockage interne réel. Les résultats de ce test suivent.
0m07.06s réel 0m00.14s utilisateur 0m06.18s systèmeÉtant donné l'énorme disparité dans le temps écoulé lors de la copie de données sur FUSE et lors de la même opération sur ext4 directement, je suppose que le coupable est le surcroît de charge généré par FUSE lui-même.
Donc, voici l'élément offensant.. donc c'est son mécanisme qui en souffre lorsque vous êtes en présence de fichiers fragmentés (c'est-à-dire, je veux dire, pas tous disposés de manière contiguë sur un segment de mémoire - notez que je ne suis pas du tout sûr de ma considération), alors qu'il n'y a aucun problème avec des fichiers individuels (petits ou grands) qui nécessitent un bloc linéaire unique (en fait, pour des opérations similaires sur, par exemple, des fichiers multimédias même plus grands que le dossier offensant, des temps très courts sont nécessaires).
Incroyable que le mécanisme amplifie de manière exponentielle la durée : d'après ce qui a été décrit, il semble que l'augmentation du nombre d'éléments auxquels l'accès doit être accordé, le temps est affecté de manière exponentielle. Merci beaucoup pour la clarification.
@Bento Comme je l'ai dit dans les commentaires, le type de mémoire installée dans un appareil mobile (eMMC), tout comme les lecteurs SSD, ne souffre pas de fragmentation, car il n'y a pas de pièces en rotation, qui sont en effet présentes dans un disque dur traditionnel. N'importe quel bloc peut être accédé en pratiquement le même temps dans les lecteurs eMMC, donc la fragmentation est sans importance. Il serait intéressant d'étudier les répercussions de l'utilisation du système de fichiers ext4, qui a été conçu en pensant aux disques durs mécaniques, sur les eMMCs. Vous pouvez vouloir vous renseigner sur le système de fichiers f2fs, si ce sujet vous intéresse.
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.
0 votes
@beeshyams Oui, j'utilise ça. J'ai essayé avec plusieurs fichiers m., mais le problème persiste toujours. Dans le passé, j'ai reçu un conseil utile ici dans S.E., quelqu'un m'a suggéré d'utiliser ADB. Cela résout efficacement le problème, mais c'est un peu gênant d'utiliser un PC à chaque fois que j'ai ce genre de dossier, de plus la question était restée : pourquoi ce changement de performance ? La référence aux programmeurs GG n'est pas si hors contexte à mon avis : premièrement, comment pouvez-vous affirmer une absolue absence de certains programmeurs GG ou quelqu'un en relation avec eux ? Deuxièmement, rien de polémique, mais simplement : quel est leur objectif ?
0 votes
J'ai trouvé ce qui est probablement le véritable coupable. Commentaire de nettoyage à venir.