Pourquoi existe-t-il tant de façons différentes de mesurer l'utilisation du disque?

Question

Lorsque je résume la taille de mes fichiers, j'obtiens un chiffre. Si je lance du, j'obtiens un autre chiffre. Si j'exécute du sur tous les fichiers de ma partition, cela ne correspond pas aux revendications de df utilisées. Pourquoi y a-t-il tant de chiffres différents pour la taille totale de mes fichiers? Les ordinateurs ne peuvent-ils pas ajouter?

En parlant d'ajout: lorsque j'ajoute les colonnes "Utilisé" et "Disponible" de df, je n'obtiens pas le chiffre total. Et ce chiffre total est plus petit que la taille de ma partition. Et si j'additionne mes tailles de partition, je n'ai pas la taille de mon disque! Ce qui donne?

Gilles &#39;SO- stop being evil&#39; · Accepted Answer

Additionner des numéros est facile. Le problème est qu'il y a de nombreux nombres différents à ajouter.

Combien d'espace disque un fichier utilise-t-il?

L'idée de base est qu'un fichier contenant n octets utilise n octets d'espace disque, plus un peu pour certaines informations de contrôle: les métadonnées du fichier (autorisations, horodatages , etc.), et un peu de surcharge pour les informations dont le système a besoin pour trouver où le fichier est stocké. Cependant, il existe de nombreuses complications.

Complications microscopiques

Considérez chaque fichier comme une série de livres dans une bibliothèque. Les fichiers plus petits ne constituent qu'un seul volume, mais les fichiers plus volumineux sont constitués de nombreux volumes, comme une encyclopédie. Afin de pouvoir localiser les fichiers, il existe un catalogue de fiches qui référence chaque volume. Chaque volume a un peu de surcharge en raison des couvertures. Si un fichier est très petit, cette surcharge est relativement importante. Le catalogue de cartes lui-même prend également de la place.

Un peu plus technique, dans un système de fichiers simple typique, l'espace est divisé en blocs . Une taille de bloc typique est de 4 Ko. Chaque fichier occupe un nombre entier de blocs. Sauf si la taille du fichier est un multiple de la taille du bloc, le dernier bloc n'est que partiellement utilisé. Ainsi, un fichier de 1 octet et un fichier de 4096 octets occupent tous les deux 1 bloc, tandis qu'un fichier de 4097 octets occupe deux blocs. Vous pouvez observer cela avec la commande du: si votre système de fichiers a une taille de bloc de 4 Ko, alors du rapportera 4 Ko pour un fichier à 1 octet.

Si un fichier est volumineux, des blocs supplémentaires sont nécessaires juste pour stocker la liste des blocs qui composent le fichier (ce sont blocs indirects ; des systèmes de fichiers plus sophistiqués peuvent optimiser cela sous la forme de extents ). Ceux-ci ne s'affichent pas dans la taille du fichier telle que rapportée par ls -l ou GNU du --apparent-size; du, qui indique l'utilisation du disque par opposition à la taille, en tient compte.

Certains systèmes de fichiers essaient de réutiliser l'espace libre restant dans le dernier bloc pour empaqueter plusieurs queues de fichiers dans le même bloc . Certains systèmes de fichiers (tels que ext4 depuis Linux 3.8 utilisent 0 blocs pour les fichiers minuscules (quelques octets seulement) qui tiennent entièrement dans l'inode.

Complications macroscopiques

En règle générale, comme indiqué ci-dessus, la taille totale indiquée par du est la somme des tailles des blocs ou des extensions utilisées par le fichier.

La taille indiquée par du peut être plus petite si le fichier est compressé. Les systèmes Unix supportent traditionnellement une forme brute de compression: si un bloc de fichiers ne contient que des octets nuls, alors au lieu de stocker un bloc de zéros, le système de fichiers peut omettre complètement ce bloc. Un fichier avec des blocs omis comme celui-ci s'appelle un fichier épars . Les fichiers clairsemés ne sont pas créés automatiquement lorsqu'un fichier contient une grande série d'octets nuls, l'application doit prendre des dispositions pour que le fichier devienne clairsemé.

Certains systèmes de fichiers tels que btrfs et zfs prennent en charge la compression à usage général .

Complications avancées

Deux caractéristiques principales des systèmes de fichiers très modernes tels que zfs et btrfs rendent la relation entre la taille du fichier et l'utilisation du disque beaucoup plus éloignée: les instantanés et la déduplication.

Instantanés sont un état figé du système de fichiers à une certaine date. Les systèmes de fichiers qui prennent en charge cette fonctionnalité peuvent contenir plusieurs instantanés pris à différentes dates. Ces instantanés prennent de la place, bien sûr. À une extrémité, si vous supprimez tous les fichiers de la version active du système de fichiers, le système de fichiers ne deviendra pas vide s'il reste des instantanés.

Tout fichier ou bloc qui n'a pas changé depuis un instantané, ou entre deux instantanés a été pris existe de manière identique dans l'instantané et dans la version active ou un autre instantané. Ceci est implémenté via copie sur écriture . Dans certains cas Edge, il est possible que la suppression d'un fichier sur un système de fichiers complet échoue en raison de l'espace disponible insuffisant - car la suppression de ce fichier nécessiterait de faire une copie d'un bloc dans le répertoire, et il n'y a plus de place pour ce bloc.

Déduplication est une technique d'optimisation du stockage qui consiste à éviter de stocker des blocs identiques. Avec des données typiques, la recherche de doublons ne vaut pas toujours la peine. zfs et btrfs prennent en charge la déduplication en tant que fonctionnalité facultative.

Pourquoi le total de `du` est-il différent de la somme des tailles de fichier?

Comme nous l'avons vu ci-dessus, la taille indiquée par du pour chaque fichier est normalement la somme des tailles des blocs ou des extensions utilisées par le fichier. Notez que par défaut, ls -l répertorie les tailles en octets, mais du répertorie les tailles en Ko ou en unités (secteurs) de 512 octets sur certains systèmes plus traditionnels (du -k force l'utilisation de kilo-octets). La plupart des unités modernes prennent en charge ls -lh et du -h pour utiliser des nombres "lisibles par l'homme" en utilisant K, M, G, etc. suffit (pour KiB, MiB, GiB) selon le cas.

Lorsque vous exécutez du sur un répertoire, il résume l'utilisation du disque de tous les fichiers de l'arborescence de répertoires, y compris les répertoires eux-mêmes . Un répertoire contient des données (les noms des fichiers et un pointeur vers l'emplacement des métadonnées du fichier), il a donc besoin d'un peu d'espace de stockage. Un petit répertoire prendra un bloc, un plus grand répertoire nécessitera plus de blocs. La quantité de stockage utilisée par un répertoire dépend parfois non seulement des fichiers qu'il contient, mais aussi de l'ordre dans lequel ils ont été insérés et dans lequel certains fichiers sont supprimés (avec certains systèmes de fichiers, cela peut laisser des trous - un compromis entre l'espace disque et les performances ), mais la différence sera minime (un bloc supplémentaire ici et là). Lorsque vous exécutez ls -ld /some/directory, la taille du répertoire est répertoriée. (Notez que la ligne "NNN total" en haut de la sortie de ls -l est un nombre sans rapport, c'est la somme des tailles en blocs des éléments listés, exprimées en Kio ou secteurs.)

Gardez à l'esprit que du inclut fichiers dot que ls ne montre pas sauf si vous utilisez le -A ou -a option.

Parfois, du rapporte moins que la somme attendue. Cela se produit s'il y a liens durs dans l'arborescence des répertoires: du ne compte chaque fichier qu'une seule fois.

Sur certains systèmes de fichiers comme ZFS sous Linux, du ne signale pas l'espace disque complet occupé par les attributs étendus d'un fichier.

Attention, s'il y a des points de montage sous un répertoire, du comptera également tous les fichiers sur ces points de montage, sauf si le -x option. Donc, par exemple, si vous voulez la taille totale des fichiers dans votre système de fichiers racine, exécutez du -x /, ne pas du /.

Si un système de fichiers est monté sur un répertoire non vide , les fichiers de ce répertoire sont masqués par le système de fichiers monté. Ils occupent toujours leur espace, mais du ne les trouvera pas.

Fichiers supprimés

Lorsqu'un fichier est supprimé , cela supprime uniquement l'entrée du répertoire, pas nécessairement le fichier lui-même. Deux conditions sont nécessaires pour supprimer réellement un fichier et ainsi récupérer son espace disque:

Le nombre de liens du fichier doit tomber à 0: si un fichier a plusieurs liens durs, la suppression de l'un n'affecte pas les autres.
Tant que le fichier est ouvert par un processus, les données restent. Ce n'est que lorsque tous les processus ont fermé le fichier que le fichier est supprimé. Le résultat fuser -m ou lsof sur un point de montage inclut les processus qui ont un fichier ouvert sur ce système de fichiers, même si le fichier est supprimé.
même si aucun processus n'a ouvert le fichier supprimé, l'espace du fichier peut ne pas être récupéré si ce fichier est le backend d'un périphérique loop. losetup -a (comme root) peut vous dire quels appareils loop sont actuellement configurés et sur quel fichier. Le périphérique de boucle doit être détruit (avec losetup -d) avant que l'espace disque puisse être récupéré.

Si vous supprimez un fichier dans certains gestionnaires de fichiers ou environnements GUI, il peut être placé dans une zone de corbeille où il peut être supprimé. Tant que le fichier peut être restauré, son espace est toujours consommé.

Quels sont ces chiffres de `df` exactement?

Un système de fichiers typique contient:

Blocs contenant des données de fichiers (y compris des répertoires) et certaines métadonnées (y compris des blocs indirects et des attributs étendus sur certains systèmes de fichiers).
Blocs libres.
Blocs réservés à l'utilisateur root.
superblocs et autres informations de contrôle.
Inodes
A journal

Seul le premier type est signalé par du. En ce qui concerne df, ce qui entre dans les colonnes "utilisé", "disponible" et total dépend du système de fichiers (bien sûr, les blocs utilisés (y compris les blocs indirects) sont toujours dans la colonne "utilisé" et inutilisés). les blocs sont toujours dans la colonne "disponible").

Les systèmes de fichiers dans la réserve ext2/ext3/ext4 5% de l'espace pour l'utilisateur root. Ceci est utile sur le système de fichiers racine, pour garder le système en marche s'il se remplit (en particulier pour la journalisation, et pour permettre à l'administrateur système de stocker un peu de données tout en résolvant le problème). Même pour les partitions de données telles que /home, conserver cet espace réservé est utile car un système de fichiers presque plein est sujet à la fragmentation. Linux essaie d'éviter la fragmentation (qui ralentit l'accès aux fichiers, en particulier sur les périphériques mécaniques rotatifs tels que les disques durs) en pré-allouant de nombreux blocs consécutifs lorsqu'un fichier est en cours d'écriture, mais s'il n'y a pas beaucoup de blocs consécutifs, cela ne peut pas fonctionner .

Les systèmes de fichiers traditionnels, jusqu'à et y compris ext4 mais pas btrfs, réservent un nombre fixe d'inodes lors de la création du système de fichiers. Cela simplifie considérablement la conception du système de fichiers, mais présente l'inconvénient que le nombre d'inodes doit être dimensionné correctement: avec trop d'inodes, l'espace est gaspillé; avec trop peu d'inodes, le système de fichiers peut manquer d'inodes avant de manquer d'espace. La commande df -i indique combien d'inodes sont utilisés et combien sont disponibles (les systèmes de fichiers où le concept n'est pas applicable peuvent signaler 0).

Fonctionnement tune2fs -l sur le volume contenant un système de fichiers ext2/ext3/ext4 rapporte certaines statistiques, y compris le nombre total et le nombre d'inodes et de blocs libres.

Une autre fonctionnalité qui peut confondre la matière est les sous-volumes (pris en charge dans btrfs , et dans zfs sous le nom datasets ). Plusieurs sous-volumes partagent le même espace, mais ont des racines d'arborescence de répertoires distinctes.

Si un système de fichiers est monté sur le réseau (NFS, Samba, etc.) et que le serveur exporte une partie de ce système de fichiers (par exemple le serveur a un /home système de fichiers et exportations /home/bob ), puis df sur un client reflète les données pour l'ensemble du système de fichiers, pas seulement pour la partie qui est exportée et montée sur le client.

À quoi sert l'espace sur mon disque?

Comme nous l'avons vu ci-dessus, la taille totale rapportée par df ne prend pas toujours en compte toutes les données de contrôle du système de fichiers. Utilisez des outils spécifiques au système de fichiers pour obtenir la taille exacte du système de fichiers si nécessaire. Par exemple, avec ext2/ext3/ext4, exécutez tune2fs -l et multipliez la taille du bloc par le nombre de blocs.

Lorsque vous créez un système de fichiers, il remplit normalement l'espace disponible sur la partition ou le volume englobant. Parfois, vous pourriez vous retrouver avec un système de fichiers plus petit lorsque vous avez déplacé des systèmes de fichiers ou redimensionné des volumes.

Sous Linux, lsblk présente une belle vue d'ensemble des volumes de stockage disponibles. Pour plus d'informations ou si vous ne disposez pas de lsblk, utilisez des outils spécialisés de gestion des volumes ou de partitionnement pour vérifier les partitions dont vous disposez. Sous Linux, il y a lvs, vgs, pvs pour LVM , fdisk pour les partitions traditionnelles de style PC ("MBR") (ainsi que GPT sur les systèmes récents), gdisk pour GPT partitions, disklabel pour les étiquettes de disque BSD, Parted , etc. Sous Linux, cat /proc/partitions donne un bref résumé. Les installations typiques ont au moins deux partitions ou volumes utilisés par le système d'exploitation: un système de fichiers (parfois plus) et un volume swap .

Certains ordinateurs ont une partition contenant BIOS ou un autre logiciel de diagnostic. Les ordinateurs avec UEFI ont une partition de chargeur de démarrage dédiée.

Enfin, notez que la plupart des programmes informatiques utilisent des unités basées sur des puissances de 1024 = 2^dix (parce que les programmeurs aiment le binaire et les pouvoirs de 2). Donc 1 kB = 1024 B, 1 Mo = 1048576 B, 1 Go = 1073741824, 1 To = 1099511627776 B,… Officiellement, ces unités sont connues sous le nom de kibibyte KiB, mebibyte MiB, etc., mais la plupart des logiciels ne rapportent que k ou kB, M ou MB, etc. D'un autre côté, les fabricants de disques durs utilisent systématiquement la métrique (unités basées sur 1000). Ce lecteur de 1 To ne représente donc que 931 Gio ou 0,904 TiB.

Pedro · Answer

Un bref résumé des complications du calcul de la taille des fichiers et des espaces disque:

L'espace que le fichier prend sur le disque est un multiplicateur du nombre de blocs qu'il prend par rapport à la taille de chaque bloc + le nombre d'inodes qu'il prend. Un fichier long de 1 octet prendra au moins 1 bloc, 1 inode et une entrée de répertoire.

Mais cela peut prendre seulement 1 entrée de répertoire supplémentaire si le fichier est un lien dur vers un autre fichier. Ce serait juste une autre référence au même ensemble de blocs.
La taille du contenu du fichier. C'est ce que ls affiche.
L'espace disque disponible n'est pas la taille du plus gros fichier dans lequel vous pouvez rentrer ni la somme de toutes les tailles de contenu de fichier qui tiendront sur le disque. C'est quelque part entre les deux. Cela dépend du nombre de fichiers (prenant des inodes), de la taille du bloc et de la façon dont le contenu de chaque fichier remplit complètement les blocs.

Cela ne fait qu'effleurer la surface des systèmes de fichiers et c'est trop simplifié. N'oubliez pas non plus que les différents systèmes de fichiers fonctionnent différemment.

stat est très utile pour repérer certaines de ces informations. Voici quelques exemples d'utilisation de stat et à quoi cela sert-il: http://landoflinux.com/linux_stat_command_examples.html

Emmanuel · Answer

Je vais illustrer ici différents cas qui font que du est différent de df.

df compte les blocs alloués au système de fichiers, du utilise les informations de taille de chaque fichier. Une différence peut avoir plusieurs causes:

1) Fichiers non liés (supprimés) qui sont toujours ouverts par l'application. Les informations du fichier sont manquantes, le bloc est toujours alloué. lsof +aL1 <filesystem> will vous aide à identifier les processus. La plupart du temps, vous devez tuer les processus pour libérer de l'espace (cela dépend du processus, parfois un rechargement de configuration est suffisant).

2) Les fichiers sous les points de montage cachés dans du mais pas dans df. debugfs can vous aide à lire le système de fichiers.

$ Sudo debugfs debugfs 1.42.12 (29-Aug-2014) debugfs: open /dev/xxx (the desired file system device) debugfs: cd /boot debugfs: ls -l 1966081 40755 (2) 0 0 4096 26-May-2016 16:28 . 2 40555 (2) 0 0 4096 11-May-2016 10:43 .. 1974291 100644 (1) 0 0 0 26-May-2016 16:28 bob <---<<< /boot/bob is hidden by /boot fs

3) fichiers clairsemés qui semble plus gros que la réalité. les blocs non alloués ne sont pas comptés par df mais la taille apparente du fichier est comptée par du.

Notez que les liens physiques ne trompent pas du

Jim Robertson · Answer

df est généralement utilisé pour voir quels sont les systèmes de fichiers, à quel point chacun est plein et où ils sont montés. Très utile lorsque vous manquez d'espace dans un système de fichiers et que vous souhaitez peut-être déplacer les choses entre les systèmes de fichiers, ou acheter un disque plus gros, etc.

du montre les détails de la quantité de stockage cumulé que chacun de ses répertoires consomme (un peu comme windirstat dans Windows). Idéal pour trouver où vous monopolisez de l'espace lorsque vous essayez de nettoyer des fichiers.

Mis à part les petites différences numériques expliquées par d'autres, je pense que les utilitaires du et df ont des fonctions très différentes.