Croissance monotone de la taille du répertoire Linux / nombre de blocs


8

Sous Linux, (peut-être en fonction de la taille du bloc du système de fichiers), lorsque je crée un répertoire et statcela, il renvoie une taille de 4096. Je peux créer des fichiers dans ce répertoire, jusqu'à un certain point, sans augmenter la taille perçue du répertoire (tel que rapporté par stat).

À un moment donné, alors que le répertoire se remplit de nombreux fichiers, la taille du répertoire augmente (je ne parle pas du contenu du répertoire, je parle des blocs consommés pour représenter le répertoire lui-même). Si des fichiers sont supprimés, la taille du répertoire reste la même.

Voici un petit exemple:

[root@uxlabtest:/]$ mkdir test
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:04.000000000 -0400
Change: 2011-07-26 14:06:04.000000000 -0400

Ensuite, touchez un tas de fichiers:

[root@uxlabtest:/]$ for i in `seq 1 10000`; do touch /test/$i; done
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:56.000000000 -0400
Change: 2011-07-26 14:06:56.000000000 -0400

Supprimez ensuite les fichiers:

[root@uxlabtest:/]$ rm -rf /test/*
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:07:11.000000000 -0400
Modify: 2011-07-26 14:07:12.000000000 -0400
Change: 2011-07-26 14:07:12.000000000 -0400

Mes questions sont:

  • Pourquoi la taille / le nombre de blocs d'un répertoire augmente-t-il de façon monotone?
  • Est-ce une fonction du système de fichiers sous-jacent ou du VFS Linux?
  • La taille du répertoire peut-elle être réduite sans supprimer et recréer le répertoire?
  • Points bonus: pointez-moi sur le code source du noyau où ce comportement est implémenté.

Je ne sais pas vraiment pourquoi cela est rejeté. Ce sont des questions légitimes et clairement exprimées avec des commandes données pour reproduire le scénario. Les réponses à ces questions satisferaient les connaissances de la communauté et seraient utiles à documenter quelque part.
loopforever

Réponses:


9

Voici les réponses qui sont vraies pour ext2 / ext3 / ext4. S'ils sont vrais pour d'autres systèmes de fichiers, cela dépend de leur implémentation.

  1. user48838 a répondu correctement à celle-ci. Plus de fichiers consomment plus de métadonnées. Ils sont alloués en blocs de 4k ou dans toute autre taille définie au moment de la création du système de fichiers
  2. Oui, c'est une caractéristique / un problème du vrai système de fichiers
  3. Dans un système de fichiers ext3, cela n'est pas possible. Uniquement en recréant le répertoire (vide)
  4. Le code source est ici et dans les fichiers associés

Mais tu as de la chance. Lorsque vous recréez la même quantité de fichiers que vous avez déjà supprimés, la taille du répertoire reste la même. Ce n'est que lorsque vous ajoutez plus de fichiers qu'il augmentera.


1
Une chose: "e2fsck -fD" devrait compacter chaque répertoire d'un système de fichiers ext2 / 3. Cela peut faire ce que désire l'OP, bien que je soupçonne que c'est lent, et le système de fichiers doit être hors ligne. Cela prend probablement plus de temps que de lier chaque fichier dans un nouveau répertoire et de supprimer les anciens.
akramer

4

Les incréments de bloc que vous voyez sont dus à la façon dont le système de fichiers gère son stockage de fichiers et les informations de gestion de fichiers associées. Dans votre situation décrite, cela semblerait être des incréments de 4K, donc chaque entrée "nouvelle" / "unique" dans le système de fichiers réservera 4K, que la taille réelle des données remplisse tout le 4K. Si les données associées occupent la totalité du 4K, un autre bloc 4K est réservé et rempli selon les besoins pour stocker l'intégralité du flux / séquence de données connexes.

En fonction des suppressions "matérielles" et "logicielles" gérées par le système de fichiers, la suppression peut ne pas (généralement pas pour la fonctionnalité "annuler la suppression") libérer immédiatement le ou les blocs réservés. Certains systèmes de fichiers peuvent différencier différents types de «suppressions» et fournir des capacités de gestion des blocs de stockage correspondantes.

L'approche et la mise en œuvre de la gestion du stockage diffèrent selon les systèmes de fichiers. Ainsi, dans les systèmes d'exploitation qui prennent en charge des systèmes de fichiers multiples / modulaires, le système d'exploitation ne fournira généralement que des «crochets» pour le système de fichiers à intégrer.


1

Ajout de quelques commentaires décousus à la bonne réponse de user48838:

Tout est un fichier, y compris les répertoires. Pour stocker toutes ces informations sur les fichiers, vous avez besoin d'espace.

Il serait également valide d'afficher, disons, `` 64B utilisé '' pour un petit répertoire et de montrer réellement la quantité d'espace utilisé, mais nous utiliserions de toute façon plusieurs 4K sur le disque, donc c'était une décision de conception de simplement montrer le quantité d'espace utilisé.

Du point de vue de la conception FS, pourquoi vous dérangeriez-vous d'avoir à vous soucier de calculer ce qui a été utilisé? Pas nécessaire. Et puis il faudrait déplacer les entrées pour éviter de laisser des trous… ick.

Lorsque des suppressions se produisent et que la taille du répertoire diminue afin que vous puissiez libérer un bloc, tout ce que la gestion devra faire avant de pouvoir le faire. Pourquoi prendre la peine d'économiser quelques Ko? Il y a de fortes chances que vous deviez quand même l'étendre plus tard.

À gauche comme exercice pour le lecteur: Réfléchissez à la raison pour laquelle votre répertoire / lost + found est créé vide mais occupe 16 Ko (sur ext3 au moins).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.