Structure de répertoire de cache

Question

Je suis en train d'implémenter la mise en cache pour mon projet. Après avoir examiné les structures de répertoire de cache, j'ai vu de nombreux exemples tels que:

cache
cache/a
cache/a/a/
cache/a/...
cache/a/z
cache/...
cache/z
...

Vous avez l’idée. Un autre exemple pour stocker des fichiers, disons que notre fichier s'appelle IMG_PARTY.JPG , une méthode courante consiste à le placer dans un répertoire nommé:

.

files/i/m/IMG_PARTY.JPG

Certaines pensées me viennent à l’esprit, mais j’aimerais connaître les véritables raisons de cette situation.

• Les systèmes de fichiers effectuant des recherches linéaires recherchent les fichiers plus rapidement lorsqu'il y en a moins dans un répertoire. Une telle structure permet d’étendre les fichiers.

• Pour ne pas gâcher les utilitaires * nix tels que rm , qui prennent un nombre fini d'arguments et supprimer un grand nombre de fichiers à la fois a tendance à être hacky (devoir le passer si rechercher etc.)

Quelle est la vraie raison? Qu'est-ce qu'un "bon"? structure de répertoire de cache et pourquoi?

Answer 1

Chaque fois que je l'ai fait, cela a été d'éviter les recherches linéaires lentes dans les systèmes de fichiers. Heureusement, du moins sous Linux, cela devient une chose du passé.

Cependant, même aujourd’hui, avec les répertoires b-tree, il sera difficile de gérer un très grand répertoire, puisqu’il faudra une journée et des jours pour obtenir la liste complète des fichiers, sans parler de la recherche du bon fichier .

Answer 2

Utilisez simplement les dates. Depuis que vous allez supprimer par date. :)

Answer 3

Si vous utilisez ls -l , tous les fichiers doivent être stat () pour obtenir des détails, ce qui augmente considérablement le temps de référencement. FS utilise des structures hachées ou linéaires.

Ainsi, même si le serveur de service a la capacité de gérer des répertoires extrêmement volumineux, il existe de bonnes raisons de ne pas disposer de grandes structures plates (elles sont également un cochon à sauvegarder)

J'ai comparé GFS2 (en cluster) avec 32 000 fichiers dans un répertoire ou dans une structure arborescente - les listes récursives étaient environ 300 fois plus rapides que l'obtention d'une liste lorsqu'elles étaient toutes dans une structure horizontale (cela pouvait prendre jusqu'à 10 minutes). pour obtenir une liste de répertoire)

EXT4 affichait des ratios similaires, mais comme le point final n'était que quelques secondes, la plupart des gens ne le remarqueraient pas.