Pourquoi, en particulier à partir d'Android 6 (pour la version 5 je ne sais pas, mais sûrement pas pour la version 4.x et inférieures), y a-t-il une lenteur excessive pour les 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 une détérioration tragique des performances du système. Qu'avaient en tête 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 dans l'espace utilisateur), car le stockage interne lui-même n'est qu'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 sous-jacente /data était formatée en ext4.
Je n'ai aucun lien d'affiliation ni avec Termux ni avec son auteur.
Les commandes utilisées étaient
cd /sdcard
time cp -r test test2Qui 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 confirmation des résultats.
Les commandes utilisées étaient
su
cd /data/media/0
time cp -r test test2Essentiellement, ce que j'ai fait ici était de me déplacer dans 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 différence de temps écoulé lors de la copie de données sur FUSE par rapport à la même opération sur ext4 directement, je suppose que le coupable est le surdébit généré par FUSE lui-même.
Alors 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 arrangé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 pas de problèmes impliqués dans les fichiers individuels (petits ou grands) qui nécessitent un seul bloc linéaire (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: sur la base de ce qui a été décrit, il semble qu'en augmentant le nombre d'éléments pour lesquels 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é 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, conçu pour les disques durs mécaniques, sur les eMMC. Vous voudrez peut-être 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 cela. J'ai essayé avec plusieurs fichiers m., mais le problème persiste toujours. Dans le passé, j'ai reçu un conseil utile ici, 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, en outre, la question était restée: pourquoi ce changement de performance? La référence aux programmeurs GG n'est pas si hors contexte selon moi: Premièrement, comment pouvez-vous affirmer une absence absolue de certains programmeurs GG ou de 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 vrai coupable. Nettoyage des commentaires à venir.