La disparité matérielle :vous venez d'acheter un nouveau disque de 1 To, mais vos outils de disque système Linux le signalent comme 977 Go. Hé, où sont passés ces 23 Go ?
Nulle part, et selon votre opinion, il est encore ou n'a jamais été là ! Cette différence provient du fait que les fabricants de disques et les programmeurs de systèmes d'exploitation utilisent différentes unités de mesure. Les fabricants de disques utilisent de vraies mesures métriques, donc 1000 Go =1 To. Cependant, dans le monde informatique, nous ne fonctionnons pas à la puissance de 10, nous fonctionnons par puissances de deux, donc pour nous, 1024 Go =1 To. Cette différence dans les unités de mesure correspond à la différence entre 1 To et 977 Go.
Wow, c'est incroyablement ennuyeux! Sans parler du fait qu'il n'est pas vraiment basé sur des normes, ce qui est l'une des préoccupations de la communauté open source, n'est-ce pas ? Essentiellement, dans l'industrie informatique, nous avons abusé du fait que 1024 est sacrément proche de 1000. Cependant, à mesure que nous obtenons des fichiers, de la mémoire, des lecteurs, des paquets, etc. de plus en plus volumineux, cette différence est de plus en plus perceptible.
Alors que faire ? Les organismes de normalisation internationaux, tels que la Commission électrotechnique internationale (CEI) et l'Organisation internationale de normalisation (ISO), ont créé une unité de mesure pour tenir compte de la différence d'utilisation entre la vraie métrique et l'approximation approximative que nous utilisons en informatique. Entrez le GiB et le TiB (les autres unités plus petites et plus grandes suivent la même nomenclature). Essentiellement, 1024 Gio =1 Tio. Cela signifie que vous pouvez toujours acheter votre disque de 1 To, mais les utilitaires de disque doivent le signaler comme 977 Gio pour indiquer que l'utilitaire de disque utilise un facteur de 1 024 pour la mesure, et non le facteur de mesure métrique, 1 000.
Les versions modernes des outils ont déjà commencé à utiliser cette méthode. Par exemple, voir mon fdisk sortie de l'utilitaire d'un système Red Hat Enterprise Linux 8.2 ci-dessous :
Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes Voici un article sur le préfixe binaire si vous souhaitez encore plus de détails.
La différence de système de fichiers
Le contenu ci-dessous est basé sur un système de fichiers étendu traditionnel qui est déployé sur de nombreux Linux différents, en particulier ext4. Cependant, Red Hat Enterprise Linux déploie désormais XFS comme système de fichiers par défaut. Vers la fin de cette section, il y a une discussion spécifique sur la façon dont ces sujets affectent XFS. Pour l'instant, concentrons-nous sur ext4.
La situation :un utilisateur signale que le système de fichiers est plein, mais lorsque je regarde le disque libre (df ) sortie, je vois ce qui suit :
[root@somehost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vdb1 991M 924M 0 100% /mnt
À partir de la sortie ci-dessus, vous remarquez que la Taille est rapporté à 991 Mo, mais la valeur Occasion est de 924 Mo, clairement pas plein. Pourtant, lorsqu'un utilisateur exécute une commande pour consommer plus d'espace disque, comme le dd commande, ils obtiennent le message suivant :
[user@somehost mnt]$ dd if=/dev/zero of=bigfile2
dd: writing to 'bigfile2': No space left on device
Cependant, s'ils utilisent touch pour créer un fichier, ils voient ceci :
[user@somehost mnt]$ touch file3
[user@somehost mnt]$ ls
bigfile file3 lost+found
De plus, si root crée un fichier en utilisant dd , cela fonctionne sans problème, comme indiqué ci-dessous :
[root@somehost mnt]# dd if=/dev/zero of=root-file count=100
100+0 records in
100+0 records out
51200 bytes (51 kB, 50 KiB) copied, 0.000748385 s, 68.4 MB/s
[root@somehost mnt]# ls
bigfile file3 lost+found root-file
De toute évidence, la création de fichiers est réussie via dd or touch si vous êtes root ! Que se passe-t-il ?
La raison touch fonctionne est que le système de fichiers est à court de blocs de données pour stocker le contenu du fichier . Cependant, le système de fichiers a beaucoup d'inodes (pointeurs de fichiers) disponibles. Cela est confirmé en utilisant une autre option avec le df commande :
[root@somehost mnt]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/vdb1 65536 14 65522 1% /mnt
Le touch La commande crée un fichier vide, ce qui signifie qu'elle consomme un inode pour stocker les métadonnées du fichier mais ne consomme aucun bloc de données associé.
La création de fichiers par l'utilisateur root fonctionne, car le système de fichiers ext4 conserve un espace réservé auquel les utilisateurs non privilégiés ne peuvent pas accéder. Seuls les processus root ou appartenant à root peuvent écrire des fichiers pour consommer cet espace disque. Pour les systèmes de fichiers ext2, ext3 et ext4, vous pouvez inspecter ces données, stockées dans le superbloc du système de fichiers, en utilisant le tune2fs commande. Dans la sortie ci-dessous, j'ai supprimé la plupart des données rapportées par tune2fs afin que je puisse afficher l'espace total et réservé :
[root@somehost mnt]# tune2fs -l /dev/vdb1
tune2fs 1.45.4 (23-Sep-2019)
Filesystem volume name: <none>
Last mounted on: /mnt
<<< OUTPUT ABRIDGED >>>
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 65536
Block count: 261888
Reserved block count: 13094
Free blocks: 253029
Free inodes: 65525
First block: 0
Block size: 4096
<< OUTPUT ABRIDGED>>
Dans la sortie ci-dessus, notez le nombre de blocs réservés paramètre. Selon le mkfs.ext4 page de manuel, la valeur par défaut est de 5 % de l'espace du système de fichiers. Sur ce système de fichiers, il s'agit d'environ 51 Mio d'espace.
Nombre de blocs réservés x taille de bloc =quantité en octets
13094 x 4096 =53633024 octets
Vous pouvez ensuite convertir les octets jusqu'à KiB ou MiB en divisant le nombre résultant par 1024 pour augmenter la taille des unités de mesure comme bon vous semble. Voici un exemple :
53633024 octets / 1024 =52376 Kio
52376 Kio / 1024 =51,15 Mio
Le système de fichiers dans son ensemble fait environ 1 Gio. Par conséquent, un nombre de blocs réservés de 5 % placerait l'espace de bloc de réserve à environ 50 Mio.
Cet ensemble de blocs réservés est ce que le dd appartenant à la racine utilisé pour stocker des données dans l'exemple ci-dessus qui fonctionnaient alors que l'utilisateur continuait à ne pas stocker de fichiers sur le système de fichiers apparemment "complet". Les administrateurs peuvent utiliser tune2fs pour augmenter ou diminuer le nombre de blocs réservés sur un système de fichiers. Toutefois, si vous augmentez cette quantité alors que le système de fichiers est actif, il doit y avoir de l'espace libre disponible contigu à la zone de bloc réservée existante du disque pour accumuler davantage de blocs réservés. En règle générale, si vous souhaitez réserver plus que la valeur par défaut, je vous recommande de le faire lorsque vous formatez le système de fichiers en utilisant une option pour mkfs.ext4 commande. Ce processus garantit qu'il y a suffisamment d'espace contigu pour allouer le nombre de blocs réservés que vous souhaitez.
Enfin, selon le système de fichiers, l'outil que vous utilisez pour inspecter le système de fichiers ou votre distribution, vous pouvez voir des outils rapporter une utilisation du système de fichiers supérieure à 100 %. Si vous voyez un rapport d'outil utilisé à 102 %, il vous indique que 100 % de l'espace disque accessible à l'utilisateur sur le système de fichiers est consommé, et que vous avez également consommé certains de ces blocs réservés.
Et XFS alors ? Plus tôt dans la section, j'ai mentionné que Red Hat Enterprise Linux 7 et 8 utilisent XFS comme format de système de fichiers par défaut. XFS utilise des blocs réservés, mais il réserve moins que les formats de système de fichiers étendus et n'autorise aucun utilisateur à accéder à cet espace. L'espace est réservé au système de fichiers XFS lui-même. Étant donné que l'espace réservé a un objectif différent - permettre au système de fichiers d'utiliser l'espace pour les opérations du système de fichiers et masquer l'espace du système - il est moins facile de rendre compte de l'utilisation des utilitaires XFS. Pourtant, cela peut être fait en utilisant une combinaison de xfs_info , en examinant le nombre et la taille des blocs, en les convertissant en KiB et en les comparant à la sortie d'un df .
Conclusion
Alors, où est votre espace disque "perdu" ? Il est caché dans les différentes unités de mesure utilisées pour signaler la capacité du disque. La façon dont cet espace est signalé et utilisé varie également selon le système de fichiers et les outils.
[ Voulez-vous essayer Red Hat Enterprise Linux ? Télécharge le maintenant gratuitement. ]