Profondeur

Je réalise quelques tests sur ma Fedora 16, relatifs au parcours d'une arborescence avec beaucoup de fichiers dedans, pour les besoins de l'exemple, plus de 160.000 fichiers vides dans un repertoire racine, et le meme nombre de fichiers, avec les même noms, dans 5 répertoires enfants (size1..5).

Par contre, ce qui me surprend, c'est que le temps d’exécution de `ls' ne varie pas d'un appel à l'autre, comme si aucune info n'était mise dans le cache du système de fichiers.

À mon avis c'est parceque l'information est déjà dans le cache avant le premier ls, si tu viens de créer tes fichiers. Cela te paraît plausible?

Du coup, mes chers lecteurs, connaissez vous "la bonne façon de faire" pour lister les répertoires de façon rapide? Y a t il des réglages kernel sympa à faire pour mettre des infos en cache de façon plus agressive?

La bonne façon c'est de ne pas avoir 160_000 fichiers par dossiers, les systèmes de fichiers non spécialisés ne sont pas fait pour ça. De mémoire, je crois qu'il n'est pas conseillé d'avoir plus d'une grosse centaine de fichiers dans un dossier, si tu veux avoir un accès rapide à tes fichiers. Je te rappelle que les fichiers dans un dossier n'ont souvent pas «d'ordre» ce qui veut dire qu'accéder à un fichier dans un dossier se fait en temps proportionnel au nombre de fichiers dans le dossier.

Par exemple ton time touch **/1plop.jpg obtient une grosse liste de fichiers que le shell passe ensuite à touch qui va rechercher chacun des fichiers, pour cela tu vas donc ouvrir 160_000 fois le même dossier et y faire

1 + 2 + ... + 160 000 = Q(160 000) où Q(x) = x * (x - 1) /2 (en gros x^2 / 2)

recherches de fichiers (pour faire stat ou mettre à jour les champs, etc.)

Si tu passes à un schéma avec 1600 dossiers imbriqués sur trois hauteurs: 32 dossiers contenant 50 dossiers contenant chacun 100 fichiers, tu va faire

160 000 ( Q(32) + Q(50) ) ouvertures de dossiers

et

1600 * Q(100) traitements sur ces fichiers

et comme Q(32) + Q(50) + Q(100)/100 est beaucoup plus petit que 160 000/2 (ça fait moins de 2000, à vue de nez)

tu remarques une grosse différence.

Si dans ton traitement le nombre d'appel systèmes sur chaque nom de fichier est grand, tu choppes un coefficient devant Q(160 000) pour la première méthode et le 1600 * Q(100) pour la deuxième méthode, et ça se passe de plus en plus mal pour la première méthode.

Pour corriger ce problème, il faut donc que tu optes pour une organisation de tes fichiers sur plusieurs niveaux de profondeur.

Par exemple, tu trouves un moyen simple de transformer ton nom de fichier en chaîne hexadecimale de 5 caractères (pour tes 160000 fichiers c'est assez), disons 12345 et tu crées un lien physique sur ton fichier de départ qui est 1/23/45 et tu fais tes traitements gourmands en appels systèmes sur cette présentation de ta collection de données.