Puis-je manquer d'espace disque en créant un très grand nombre de fichiers vides?


35

Il est bien connu que les fichiers texte vides ont zéro octet:

entrez la description de l'image ici

Cependant, chacun d'entre eux contient des métadonnées qui, selon mes recherches, sont stockées dans des inodes et utilisent effectivement de l' espace .

Compte tenu de cela, il me semble logique qu'il soit possible de remplir un disque en créant simplement des fichiers texte vides. Est-ce correct? Si tel est le cas, combien de fichiers texte vides devrais-je remplir un disque de, disons, 1 Go?


Pour faire quelques vérifications, je cours df -imais cela indique apparemment le pourcentage d'inodes utilisés (?) Plutôt que leur poids.

Filesystem             Inodes  IUsed    IFree IUse% Mounted on
udev                   947470    556   946914    1% /dev
tmpfs                  952593    805   951788    1% /run
/dev/sda2            28786688 667980 28118708    3% /
tmpfs                  952593     25   952568    1% /dev/shm
tmpfs                  952593      5   952588    1% /run/lock
tmpfs                  952593     16   952577    1% /sys/fs/cgroup
/dev/sda1                   0      0        0     - /boot/efi
tmpfs                  952593     25   952568    1% /run/user/1000
/home/lucho/.Private 28786688 667980 28118708    3% /home/lucho

Réponses:


40

Cette sortie suggère des 28786688inodes globaux, après quoi la prochaine tentative de création d'un fichier dans le système de fichiers racine (périphérique /dev/sda2) renverra ENOSPC("Plus aucun espace disponible sur le périphérique").

Explication: dans la conception originale du système de fichiers * nix, le nombre maximal d'inodes est défini lors de la création du système de fichiers. Un espace dédié leur est attribué. Vous pouvez manquer d’inodes avant de manquer d’espace pour les données, ou inversement. Le système de fichiers Linux par défaut le plus courant ext4a toujours cette limitation. Pour plus d'informations sur les tailles d'inodes sur ext4, consultez la page de manuel relative à mkfs.ext4.

Linux prend en charge d'autres systèmes de fichiers sans cette limitation. Sur btrfs, l'espace est alloué dynamiquement. "La structure d'inode est relativement petite et ne contiendra pas de données de fichier incorporées ni de données d'attribut étendu." (ext3 / 4 alloue de la place dans les inodes pour les attributs étendus ). Bien sûr, vous pouvez toujours manquer d’espace disque en créant trop d’entrées de métadonnées / répertoires.

En y réfléchissant, tmpfs est un autre exemple où les inodes sont alloués dynamiquement. Il est difficile de savoir ce que le nombre maximal d'inodes rapportés par df -isignifie réellement dans la pratique pour ces systèmes de fichiers. Je ne donnerais aucun sens à la valeur indiquée.


"XFS alloue également les inodes de manière dynamique. JFS en fait de même. Reiserfs le fait également. F2FS de même. Les systèmes de fichiers Unix traditionnels allouent les inodes de manière statique au moment de mkfs. l'exception, pas la règle.

"BTW, XFS vous permet de limiter le pourcentage maximum d’espace utilisé par les inodes. Ainsi, vous risquez de manquer d’inodes avant d’arriver au point où vous ne pouvez pas ajouter de fichiers existants. (La valeur par défaut est 25% pour les systèmes de fichiers.) moins de 1 To, 5% pour les systèmes de fichiers jusqu’à 50 To, 1% pour les plus gros.) Quoi qu’il en soit, cette utilisation de l’espace dans les métadonnées (inodes et cartes d’extension) sera reflétée dans des paramètres normaux df -h"- Peter Cordes dans un commentaire à cette réponse


Alors, êtes-vous en train de dire que si je crée 28786688-667980=28118708des fichiers vides, je vais manquer d’inodes et «casser mon système»?
luchonacho

1
XFS alloue également les inodes de manière dynamique. JFS aussi. De même que Reiserfs. Il en va de même pour F2FS . Les systèmes de fichiers Unix traditionnels allouent les inodes statiquement au moment de mkfs, de même que les systèmes de fichiers modernes tels que ext4, qui y retracent leur héritage, mais de nos jours, ce n’est pas une règle, mais une exception. (Sauf si vous pesez les choses par base installée, dans lesquelles il est probablement exact de dire que la plupart des systèmes de fichiers actuellement sur disque sur des systèmes * nix dans la nature ont des inodes alloués de manière statique.)
Peter Cordes

BTW, XFS vous permet de limiter le pourcentage maximum d’espace utilisé par les inodes. Vous pouvez donc manquer d’inodes avant d’arriver au point où vous ne pouvez pas ajouter des fichiers existants. (La valeur par défaut est 25% pour les systèmes de stockage inférieurs à 1 To, 5% pour les systèmes de fichiers jusqu’à 50 To, 1% pour les systèmes plus volumineux.) Quoi qu’il en soit, cette utilisation de l’espace sur les métadonnées (inodes et cartes d’extension) sera reflétée dans df -h@luchonacho.
Peter Cordes

26

La création de fichiers vides implique l'utilisation des éléments suivants:

  • inodes, un par fichier;
  • des entrées de répertoire supplémentaires, également une par fichier, mais agrégées.

Le nombre d'inodes disponibles est souvent déterminé lors de la création d'un système de fichiers et ne peut pas être modifié (certains systèmes de fichiers tels que Btrfs ou XFS allouent les inodes de manière dynamique). C'est ce qui est mesuré par df -i. Lorsque vous êtes à court d'inodes, vous ne pouvez pas créer de nouveaux fichiers ou répertoires, même si vous avez de l'espace disque disponible.

Les entrées de répertoire occupent également de l'espace, à partir de l'espace disque disponible. Vous pouvez le voir en regardant la taille d'un répertoire: il s'agit toujours d'un multiple de la taille du bloc et lorsqu'un répertoire contient beaucoup de fichiers, sa taille augmente. Si vous manquez d'espace disque, vous ne pourrez peut-être pas créer de nouveaux fichiers ou répertoires dans un répertoire «plein» ( c'est -à- dire , où l'ajout d'un nouveau fichier impliquerait l'allocation d'un nouveau bloc), même si vous avez des inodes disponibles.

Alors oui, il est possible de manquer d’espace disque en utilisant uniquement des fichiers vides.


Il me faudrait donc créer suffisamment de fichiers vides pour arriver à une utilisation à 100% des inodes?
luchonacho

@luchonacho oui, effectivement un fichier vide par inode.
Stephen Kitt

Notez également les attributs étendus qui peuvent ajouter de l'espace en plus de cela. Par exemple, si le répertoire contient de nombreuses listes de contrôle d'accès par défaut, la création d'un fichier nécessitera de l'espace pour stocker ces listes.
Stéphane Chazelas

OK, je suis corrigé. Le problème, c’est étrange pour moi à la fois avec les polices de rendu et de largeur fixe de mon navigateur. Par curiosité, comment les insérez-vous? Votre clavier a-t-il une touche différente pour ce caractère et celle U + 0022?
Stéphane Chazelas

Merci, par curiosité, j'ai vérifié si elles étaient sur la disposition de mon clavier britannique et effectivement elles sont sur AltGr + Maj + V / B (guillemets doubles sans décalage). Je vais rester avec U + 0022 si.
Stéphane Chazelas

7

Argument de pure logique:

Un nom de fichier est constitué d'un nombre d'octets différent de zéro. Même avec une compression maximale théorique dans un système de fichiers hypothétique conçu pour permettre la quantité maximale absolue de noms de fichiers, chaque nom de fichier consommera toujours au moins un bit quelque part sur votre disque physique. Probablement plus, mais "1 bit par fichier" est le minimum trivial.

Calculez le nombre de bits pouvant tenir sur vos plateaux, soit le nombre maximum théorique de fichiers (vides ou non vides) que vous pouvez stocker.

Donc, la réponse est oui. Éventuellement, vous manquerez d’espace, quel que soit le stockage que vous utilisez, si vous continuez d’ajouter des fichiers vides. Évidemment, vous allez manquer beaucoup plus tôt que le maximum calculé de cette façon, mais vous le manquerez.


0

Tout simplement non, mais vous pouvez manquer d’inodes sur Linux, ce qui revient à manquer d’espace.

vous pouvez essayer quelque chose comme ça dans votre coquille n=0; while :; do touch $n; let n=n+1; done

Assurez-vous simplement de l'exécuter sur la machine virtuelle, sinon vous serez à court d'inodes.


Que fait cette commande?
luchonacho

Il commence par une véritable boucle infinie qui, à chaque tour, crée un nom de fichier qui est un entier commençant par 0, puis 1 2 3 ... il finira par créer suffisamment de fichiers pour utiliser tous les inodes du système de fichiers.
in1t3r

1
Si vous exécutez cette commande sur votre partition / home si elle est indépendante, vous ne rencontrerez aucun problème avec la partition /, vous ne pourriez plus écrire sur votre partition / home. Ma suggestion est de créer un répertoire nommé inodetest cd, puis d’exécuter une commande après avoir détecté des erreurs qui empêchent de créer des fichiers dans le système de fichiers. Appuyez sur ctrl + C et exécutez-vous rm -fr inodetestpour supprimer tous ces fichiers vides et travailler à nouveau normalement. :)
in1t3r

0

Vous ne pouvez pas remplir le disque en créant des fichiers vides - le disque aura encore beaucoup d’espace pour les nouveaux fichiers. Mais oui, vous pouvez épuiser la réserve finie d’inodes libres du système de fichiers - vous ne pouvez plus créer de nouveaux fichiers (même si votre disque - pour l’espace utilisé lointain - est pratiquement vide). C'est juste la liste des inodes du système de fichiers qui a été utilisée, pas le disque ... donc le système de fichiers est plein, alors que le disque est pratiquement vide. La table inode utilise de l'espace sur le disque, mais la table ne grandit pas lorsque vous ajoutez des fichiers, tout comme une feuille de papier ne grandit pas lorsque vous écrivez sur ses lignes.

(une réponse-en-un-commentaire de Baard Kopperud)


Vous n'êtes pas sûr d'avoir besoin d'une autre réponse qui dit la même chose ?
Jeff Schaller
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.