Die Hardware-Disparität:Sie haben gerade ein schönes neues 1-TB-Laufwerk gekauft, aber Ihre Linux-Systemfestplatten-Tools melden es als 977 GB. Hey, wo sind die 23 GB geblieben?
Nirgendwo, und je nach Ihrer Meinung, ist es entweder noch da oder war nie da! Dieser Unterschied kommt von Festplattenherstellern und Programmierern von Betriebssystemen, die unterschiedliche Maßeinheiten verwenden. Festplattenhersteller verwenden echte metrische Messungen, also 1000 GB =1 TB. In der Computerwelt arbeiten wir jedoch nicht mit Zehnerpotenzen, sondern mit Zweierpotenzen, also sind für uns 1024 GB =1 TB. Dieser Unterschied in den Maßeinheiten ist der Unterschied zwischen 1 TB oder 977 GB.
Wow, das ist unglaublich nervig! Ganz zu schweigen davon, dass es nicht wirklich standardbasiert ist, worum es in der Open-Source-Community geht, oder? Im Grunde haben wir in der Computerbranche die Tatsache missbraucht, dass 1024 verdammt nahe an 1000 liegt. Je größer die Dateien, Speicher, Laufwerke, Pakete usw. werden, desto deutlicher wird dieser Unterschied jedoch immer deutlicher.
Was ist also zu tun? Internationale Normungsgremien wie die International Electrotechnical Commission (IEC) und die International Organization for Standardization (ISO) haben eine Maßeinheit geschaffen, um den Unterschied in der Verwendung zwischen der wahren Metrik und der groben Annäherung zu berücksichtigen, die wir beim Rechnen verwendet haben. Geben Sie GiB und TiB ein (die anderen kleineren und größeren Einheiten folgen derselben Nomenklatur). Im Wesentlichen sind 1024 GiB =1 TiB. Das bedeutet, dass Sie Ihr 1-TB-Laufwerk immer noch kaufen können, aber Festplattendienstprogramme sollten es als 977 GiB melden, um zu verdeutlichen, dass das Festplattendienstprogramm einen Faktor von 1024 für die Messung verwendet, nicht den metrischen Messfaktor 1000.
Moderne Versionen von Tools haben bereits damit begonnen, diese Methode zu verwenden. Siehe zum Beispiel mein fdisk Utility-Ausgabe von einem Red Hat Enterprise Linux 8.2-System unten:
Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes Hier ist ein Artikel über binäre Präfixe, wenn Sie noch mehr Details wünschen.
Die Diskrepanz im Dateisystem
Der folgende Inhalt basiert auf einem traditionellen erweiterten Dateisystem, das auf vielen verschiedenen Linuxen bereitgestellt wird, insbesondere ext4. Allerdings setzt Red Hat Enterprise Linux jetzt XFS als Standarddateisystem ein. Gegen Ende dieses Abschnitts gibt es eine spezielle Diskussion darüber, wie sich diese Themen auf XFS auswirken. Konzentrieren wir uns zunächst auf ext4.
Die Situation:Ein Benutzer meldet, dass das Dateisystem voll ist, aber wenn ich mir die Festplatte ansehe, ist sie frei (df ) ausgegeben, sehe ich Folgendes:
[root@somehost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vdb1 991M 924M 0 100% /mnt
Aus der obigen Ausgabe sehen Sie, dass die Size wird mit 991 MB gemeldet, aber die Verwendet ist 924 MB, eindeutig nicht voll. Wenn ein Benutzer jedoch einen Befehl ausführt, um mehr Speicherplatz zu verbrauchen, wie z. B. dd Befehl erhalten sie die folgende Meldung:
[user@somehost mnt]$ dd if=/dev/zero of=bigfile2
dd: writing to 'bigfile2': No space left on device
Allerdings, wenn sie touch verwenden Um eine Datei zu erstellen, sehen sie Folgendes:
[user@somehost mnt]$ touch file3
[user@somehost mnt]$ ls
bigfile file3 lost+found
Zusätzlich erstellt root eine Datei mit dd , funktioniert es ohne Probleme, wie unten gezeigt:
[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
Offensichtlich ist das Erstellen von Dateien durch dd or touch erfolgreich wenn du root bist! Was ist los?
Der Grund touch funktioniert, ist, dass das Dateisystem keine Datenblöcke zum Speichern von Inhalten von Dateien hat . Das Dateisystem hat jedoch viele Inodes (Dateizeiger) zur Verfügung. Dies wird durch die Verwendung einer weiteren Option mit dem df bestätigt Befehl:
[root@somehost mnt]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/vdb1 65536 14 65522 1% /mnt
Die touch Der Befehl erstellt eine leere Datei, was bedeutet, dass er einen Inode zum Speichern der Dateimetadaten verbraucht, aber keine zugehörigen Datenblöcke verbraucht.
Die Dateierstellung des Root-Benutzers funktioniert, weil das ext4-Dateisystem einen reservierten Bereich hält, auf den nicht privilegierte Benutzer nicht zugreifen können. Nur Root- oder Root-eigene Prozesse können Dateien schreiben, um diesen Speicherplatz zu verbrauchen. Bei ext2-, ext3- und ext4-Dateisystemen können Sie diese Daten, die im Dateisystem-Superblock gespeichert sind, mit tune2fs überprüfen Befehl. In der Ausgabe unten habe ich die meisten der von tune2fs gemeldeten Daten entfernt damit ich den gesamten und reservierten Platz anzeigen kann:
[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>>
Beachten Sie in der obigen Ausgabe die Reservierte Blockanzahl Parameter. Laut mkfs.ext4 Manpage, dies ist standardmäßig auf fünf Prozent des Speicherplatzes im Dateisystem eingestellt. Auf diesem Dateisystem sind es ungefähr 51 MiB Speicherplatz.
Anzahl der reservierten Blöcke x Blockgröße =Anzahl in Bytes
13094 x 4096 =53633024 Bytes
Sie können die Bytes dann in KiB oder MiB umwandeln, indem Sie die resultierende Zahl durch 1024 teilen, um die Maßeinheiten nach Belieben zu vergrößern. Hier ist ein Beispiel:
53633024 Byte / 1024 =52376 KiB
52376 KiB / 1024 =51,15 MiB
Das Dateisystem als Ganzes ist ungefähr 1 GiB groß, sodass eine reservierte Blockanzahl von fünf % den reservierten Blockspeicher auf ungefähr 50 MiB bringen würde.
Dieser Satz von reservierten Blöcken ist das, was der root-eigene dd ist verwendet, um Daten im obigen Beispiel zu speichern, das funktionierte, während der Benutzer weiterhin keine Dateien im scheinbar "vollen" Dateisystem speicherte. Administratoren können tune2fs verwenden um die Anzahl der reservierten Blöcke in einem Dateisystem entweder zu erhöhen oder zu verringern. Wenn Sie diesen Betrag jedoch erhöhen, während das Dateisystem aktiv ist, muss freier Speicherplatz verfügbar sein, der an den vorhandenen reservierten Blockbereich der Festplatte angrenzt, um mehr reservierte Blöcke anzusammeln. Wenn Sie mehr als den Standardwert reservieren möchten, empfehle ich im Allgemeinen, dies zu tun, wenn Sie das Dateisystem formatieren, indem Sie eine Option für mkfs.ext4 verwenden Befehl. Dieser Prozess stellt sicher, dass ausreichend zusammenhängender Speicherplatz vorhanden ist, um die gewünschte Anzahl reservierter Blöcke zuzuweisen.
Zu guter Letzt, abhängig vom Dateisystem, dem Tool, das Sie verwenden, um das Dateisystem zu inspizieren, oder Ihrer Distribution, sehen Sie möglicherweise, dass Tools eine Nutzung des Dateisystems von mehr als 100 % melden. Wenn Sie einen Toolbericht sehen, der zu 102 % belegt ist, bedeutet dies, dass 100 % des für Benutzer zugänglichen Speicherplatzes auf dem Dateisystem belegt sind und dass Sie auch einige dieser reservierten Blöcke belegt haben.
Was ist also mit XFS? Weiter oben in diesem Abschnitt habe ich erwähnt, dass Red Hat Enterprise Linux 7 und 8 XFS als standardmäßiges Dateisystemformat verwenden. XFS verwendet reservierte Blöcke, aber es reserviert weniger als die erweiterten Dateisystemformate und erlaubt keinem Benutzer den Zugriff auf diesen Speicherplatz. Der Speicherplatz ist für die Verwendung durch das XFS-Dateisystem selbst reserviert. Da der reservierte Speicherplatz einen anderen Zweck hat – dem Dateisystem zu ermöglichen, den Speicherplatz für Dateisystemoperationen zu nutzen und den Speicherplatz vor dem System zu verbergen – ist es weniger einfach, über die Verwendung der XFS-Dienstprogramme zu berichten. Dennoch kann dies mit einer Kombination aus xfs_info erfolgen , die Blockanzahl und -größe betrachten, diese in KiB umwandeln und mit der Ausgabe eines df vergleichen .
Schluss machen
Wo ist also Ihr "verlorener" Speicherplatz? Es ist in den verschiedenen Maßeinheiten verborgen, die zur Angabe der Festplattenkapazität verwendet werden. Wie dieser Speicherplatz gemeldet und verwendet wird, variiert ebenfalls je nach Dateisystem und Tools.
[ Möchten Sie Red Hat Enterprise Linux ausprobieren? Laden Sie es jetzt kostenlos herunter. ]