Disons que vous commencez avec une liste vierge, c'est-à-dire que vous n'avez pas du tout accédé au système de fichiers. Supposons maintenant que vous exécutez stat («/ some / dir / file»). Le noyau doit d'abord trouver le fichier qui, en termes techniques, est appelé l'inode. Il commence par regarder dans le superbloc du système de fichiers, qui stocke l'inode du répertoire racine. Ensuite, il ouvre le répertoire racine, en trouve «certains», l'ouvre, trouve «dir», etc. finissant par trouver l'inode pour le fichier.
Ensuite, vous devez réellement lire les données d'inode. Après la première lecture, il est également mis en cache dans la RAM. Ainsi, une lecture seule doit avoir lieu une seule fois.
Considérez le HD comme un vieux tourne-disque, une fois que vous êtes au bon endroit avec l'aiguille, vous pouvez continuer à lire des trucs rapidement pendant qu'il tourne. Cependant, une fois que vous devez déménager dans un endroit différent, appelé «chercher», vous faites quelque chose de très différent. Vous devez déplacer physiquement le bras, puis attendre que le plateau tourne jusqu'à ce que le bon endroit soit sous l'aiguille. Ce type de mouvement physique est intrinsèquement lent, donc les temps de recherche de disques sont assez longs.
Alors, quand cherchons-nous? Cela dépend bien sûr de la disposition du système de fichiers. Les systèmes de fichiers essaient de stocker les fichiers consécutivement pour augmenter les performances de lecture, et ils essaient généralement de stocker les inodes pour un seul répertoire les uns à côté des autres, mais tout dépend de choses comme le moment où les fichiers sont écrits, la fragmentation du système de fichiers, etc. Donc, dans le pire des cas cas, chaque statistique d'un fichier provoquera une recherche, puis chaque ouverture du fichier provoquera une deuxième recherche. C'est pourquoi les choses prennent autant de temps lorsque rien n'est mis en cache.
Certains systèmes de fichiers sont meilleurs que d'autres, la défragmentation peut aider. Vous pouvez faire certaines choses dans les applications. Par exemple, GIO trie les inodes reçus de readdir () avant de les déclarer en espérant que le numéro d'inode a une sorte de relation avec l'ordre du disque (il a généralement) minimisant ainsi les recherches aléatoires d'avant en arrière.
Une chose importante est de concevoir votre stockage de données et vos applications pour minimiser la recherche. Par exemple, c'est pourquoi Nautilus lisant / usr / bin est lent, car les fichiers qu'il contient n'ont généralement pas d'extension dont nous avons besoin pour effectuer un reniflement magique pour chacun. Donc, nous devons ouvrir chaque fichier => une recherche par fichier => slooooow. Un autre exemple est celui des applications qui stockent des informations dans de nombreux petits fichiers, comme le faisait gconf, également une mauvaise idée. Quoi qu'il en soit, dans la pratique, je ne pense pas que vous puissiez faire grand-chose, sauf essayer de masquer les latences.