ext4: Wie wird der Dateisystemspeicherplatz berücksichtigt?


16

Ich habe kürzlich ein 1,5-TB-Laufwerk mit der Absicht formatiert, ntfs durch ext4 zu ersetzen.

Dann bemerkte ich, dass die von mir gespeicherten Dateien nicht auf die neue Partition passen.

df:

ext4 (ext3 & ext2 show the same behavior)
Filesystem      1K-blocks   Used  Available Use% Mounted on
/dev/sdb1      1442146364   71160 1442075204    1% /media/Seagate

ntfs (similar to all other options that gparted offers):
/dev/sdb1      1465137148  110700 1465026448    1% /media/Seagate

Diese Differenz von 1K-Blöcken bedeutet eine unglaubliche Verringerung des nutzbaren Speicherplatzes um 22 GiB.

Ich habe bereits ausgeführt

tune2fs -O \^has_journal
tune2fs -r 0
tune2fs -m 0

Es ist nicht überraschend, dass dies keine Auswirkungen auf Blöcke hat, die einfach nicht vorhanden sind.

Trotzdem meldet fdisk, dass die ext4-Partition die gesamte Festplatte abdeckt.

fdisk -l /dev/sdb:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  2930277167  1465138583+  ee  GPT

Und so meldet zB resize2fs, dass es nichts zu tun gibt!

dumpe2fs -h /dev/sdb1:
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d6fc8971-89bd-4c03-a7cd-abdb945d2173
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284288
Reserved block count:     0
Free blocks:              360518801
Free inodes:              91578357
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat May 21 17:12:04 2011
Last mount time:          Sat May 21 17:15:30 2011
Last write time:          Sat May 21 17:24:32 2011
Mount count:              1
Maximum mount count:      32
Last checked:             Sat May 21 17:12:04 2011
Check interval:           15552000 (6 months)
Next check after:         Thu Nov 17 16:12:04 2011
Lifetime writes:          1372 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      c334e6ef-b060-45d2-b65d-4ac94167cb09
Journal backup:           inode blocks

Was nutzt diesen fehlenden Platz?

Antworten:


21

Mal sehen. Die Gerätegröße beträgt 1.465.138.583½ kB = 1.500.301.909.504 B. Das Dateisystem besteht aus 366.284.288 Blöcken zu je 4096 B, das sind 1.500.300.443.648 B. Ich weiß nicht, wofür die restlichen 1.465.856 B (1.4 MB) verwendet werden (zusätzliche Kopien des Superblocks) Ich weiß, dass am Anfang ein paar kB Platz für den Bootloader sind.

Das Dateisystem enthält 91.578.368 Inodes mit jeweils 256 Bytes, was 23.444.062.208 B (ca. 22 GB, Hinweis, Hinweis) ausmacht. Dann gibt es 1.442.146.364 kB = 1.476.757.876.736 B für den Dateiinhalt. Dies macht 23.444.062.208 B + 1.476.757.876.736 B = 1.500.201.938.944 B aus. Die verbleibende Größe beträgt 98.504.704 B = 24.029 Blöcke, was im richtigen Bereich für die Journalgröße liegt.

Wie Sie sehen, ist alles berücksichtigt. (Ok, fast alles, aber wir sprechen von Megabyte, nicht von Gigabyte.)


1
Danke, das ist es sicherlich. (So ​​wie du es präsentierst, auch ganz offensichtlich - ich hätte etwas mehr darüber nachdenken sollen.) Also habe ich die Partition mit "mkfs.ext4 -m 0 -O sparse_super -T largefile4" neu erstellt, da sie nur ein paar Tausend größer sein soll Dateien, jetzt sind 357728 Inodes vs. 1464880364 Blöcke verfügbar.
Sonstiges

13

Zunächst einmal bedeutet der Unterschied im verfügbaren Speicherplatz nicht, dass Speicherplatz "verschwendet" ist. Es wird nicht verschwendet, da es für das Funktionieren des Dateisystems von grundlegender Bedeutung ist. Sie sollten Ext4 und NTFS nicht auf diese Weise vergleichen, ohne ein sehr großes "sondern" anzugeben, das alle Design- und Strukturunterschiede zwischen Dateisystemen sowie die Besonderheiten jeder Implementierung (z. B. wie jeder Treiber der VFS-Ebene freien Speicherplatz meldet).

Stellen Sie sich die Partition als einen riesigen Raum vor, in dem Sie alle vorhandenen Daten ablegen können. Wenn Sie nur ein Datenelement mit einer Größe haben, die der Partition entspricht, können Sie es einfach am Anfang der Partition schreiben und sich damit abfinden. Aber du nicht. Stattdessen haben Sie möglicherweise Tausende kleiner Dateien, und alle diese Dateien sind auf unterschiedliche Weise gruppiert, und jede Datei ist mit vielen anderen kleinen Datenelementen (Name, Datum / Uhrzeit und Berechtigungen) usw. verknüpft. Sie müssen den großen Bereich des Ordners organisieren partitionieren, damit Sie schnell und effizient auf alle diese Daten zugreifen können. Außerdem müssen Sie sich damit befassen, wie Sie neue Datenelemente schreiben und alte Datenelemente effizient verwerfen können. Sie benötigen Datenstrukturen .

Und es gibt viele Datenstrukturen . Einige von ihnen sind sehr dumm, andere ermöglichen das schnellere Abrufen von Daten auf Kosten langsamerer Schreibvorgänge, andere ermöglichen das schnellere Schreiben auf Kosten von Lesevorgängen, andere sind möglicherweise sowohl für Lese- als auch für Schreibvorgänge sehr gut, erfordern jedoch lange Pausen und Leerlauf-Overhead, während die Daten usw. neu angeordnet werden

Sie möchten auf jeden Fall ein System, das:

  1. Ist sehr schnell, um Informationen darüber zu schreiben;
  2. Ist sehr schnell, um Informationen daraus abzurufen;
  3. Ist gut in der Organisation und Verwaltung der darin gespeicherten Informationen;
  4. Nutzt den Speicherplatz (Partition), auf dem das Dateisystem gespeichert ist, gut aus.
  5. Ist widerstandsfähig gegen Hardwareprobleme, sodass Sie bei teilweisen Systemfehlern immer noch die meisten oder alle Informationen zurückerhalten.
  6. Ist widerstandsfähig gegen Softwareprobleme, sodass ein Fehler in einer Anwendung oder eine installierte schädliche Anwendung Ihre Daten nicht dauerhaft zerstört.
  7. Ist widerstandsfähig gegen menschliche Fehler, sodass es Ihnen verzeiht, wenn Sie dem System versehentlich befehlen, etwas zu löschen, das Sie nicht sollten (auch als Papierkorb / Papierkorb bezeichnet).

Hochleistungs-Dateisysteme ermöglichen sehr schnelles Lesen und Schreiben auf Kosten von Speicherplatz. Einige der schnellsten in Dateisystemen verwendeten Datenstrukturen, wie z. B. Hash-Tabellen und B-Bäume , sind sehr komplex und belegen mehr Speicherplatz als tatsächlich verwendet, um sehr schnelle Zugriffe zu ermöglichen.

Ext4 hat andere wichtige Eigenschaften. Es gibt keine einzelne Fehlerstelle im Dateisystem. Es gibt viele Kopien kritischer Daten, die über die Partition verteilt sind, während einige andere Dateisysteme (ich kann nicht für NTFS sagen) all Ihre Daten möglicherweise unlesbar machen, wenn ein Fehler an der richtigen Stelle auftritt. Außerdem reserviert Ext4 bereits in der Phase der Dateisystemerstellung viel Speicherplatz für Ihre Daten, während NTFS mit Ihren Daten wächst.


1
Danke, dieser letzte Teil ist entscheidend. Mir war nicht bewusst, dass ext4 (vergleichsweise) viel Arbeit zur Erstellungszeit leistet, die ntfs während des Betriebs erledigt.
Sonstiges

1
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! 
The util fdisk doesn't support GPT. Use GNU Parted.

Diese Meldung gibt an, dass der Datenträger eine GPT-Partitionierung verwendet und dieses fdiskTool nur den älteren MBR-Stil versteht.

Um versehentliche Neuformatierungen zu verhindern, wenn GPT-partitionierte Datenträger in ältere nicht GPT-fähige Systeme eingesteckt werden, enthält das GPT-Partitionsschema einen "MBR-Schutz": eine vollständig gefälschte Partitionstabelle, die im Grunde sagt, dass dieser Datenträger von einem Partitionstyp, den Sie verwenden, vollständig verwendet wird "Keine Ahnung von" für ein Betriebssystem oder Tool, das nur die MBR - Partitionierung versteht.

Um eine genaue Anzeige der Partitionstabelle Ihrer zu erhalten /dev/sdb, verwenden Sie:

parted /dev/sdb print
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.