Größe der ext4-Partition / Diskrepanzen zwischen freiem Speicherplatz

Beim Erstellen einer 250-GB-Backup-Partition für meine Daten sind mir viele Unterschiede zwischen der angegebenen Partitionsgröße und dem freien Speicherplatz in Nautilus, gParted, df, tune2fs usw. aufgefallen.

Zuerst dachte ich, es sei eine GiB / GB-Verwirrung. Es war nicht .

Dann dachte ich, es könnten die reservierten Blöcke von ext4 sein. Es war nicht .

Ich bin völlig verwirrt. Hier sind einige Bilder. Hier sind die Schritte:

• Erstens NTFS. 524288000 Sektoren x 512 Bytes / Sektor = 268435456000 Bytes = 268,4 GB = 250 GiB.

Nautilus sagt " Total Capacity: 250.0 GB " (obwohl es sich eigentlich um GiB handelt, nicht um GB). Abgesehen von dieser geringfügigen Fehlbezeichnung, soweit, so gut

• Nun dieselbe Partition, formatiert als ext4 mit gparted:

Erster, letzter und gesamter Sektor sind gleich. Es ist die gleiche 250GiB-Partition. Verwendete Größe ist 4,11 GB (reservierte Blöcke vielleicht?)

Nee. Sieht aus wie reservierte Blöcke sind 12,7 GiB (~ 5%. Autsch! ). Aber ... warum beträgt die Gesamtkapazität jetzt nur noch 246,1 GiB ??? . Dieser Unterschied entspricht in etwa dem von gparted gemeldeten Wert von 4,11 GiB. Aber ... wenn es nicht von reservierten Blöcken ist, was ist es? Und warum hat gparted nicht gemeldet, dass 12,7 GB Speicherplatz genutzt werden?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  234G   1% /media/BACKUP

dfStimmt mit Nautilus im angegebenen freien Speicherplatz überein. Aber .. nur 188M verwendet? Sollte es nicht ~ 12GB sein? Und die Gesamtkapazität ist immer noch falsch. Also rannte ich los tune2fs, um ein paar Hinweise zu finden. (irrelevante Ausgabe wird weggelassen)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal 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 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     3276800
Free blocks:              64459851
First block:              0
Block size:               4096

65536000 Gesamtblöcke * 4096 Bytes / Block = 268435456000 Bytes = 268,4 GB = 250 GiB. Es entspricht gparted.

3276800 reservierte Blöcke = 13421772800 Bytes = 13,4 GB = 12,5 GiB. Es passt (wieder sozusagen) zu Nautilus.

64459851 freie Blöcke = 264027549696 Bytes = 264,0 GB = 245,9 GiB. Warum? Sollte es nicht 250-12,5 = 237,5 (oder 250- (12,5 + 4,11) = ~ 233) sein?

Reservierte Blöcke entfernen:

$ sudo tune2fs -m 0 /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Setting reserved blocks percentage to 0% (0 blocks)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal 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 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     0
Free blocks:              64459851
Block size:               4096

Wie erwartet, gleiche Blockanzahl, 0 reservierte Blöcke, aber ... gleiche freie Blöcke ? Habe ich nicht gerade 12,5 GiB freigegeben?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  246G   1% /media/BACKUP

Sieht aus wie ich. Der verfügbare Speicherplatz stieg von 233 auf 245,9 GiB. gparted kümmerte sich überhaupt nicht darum und zeigte genau die gleichen Informationen! (Nutzlos, um einen identischen Screenshot zu posten)

Was für ein riesiges Durcheinander!

Ich habe versucht, es so gut wie möglich zu dokumentieren. Kann mir jemand einen Hinweis geben, was hier vor sich geht?

• Was sind diese mysteriösen 4.11 GiB, die in NTFS -> ext4-Formatierungen fehlen?
• Warum gibt es so viele Unterschiede zwischen gparted, Nautilus, tune2fs, df?
• Was ist los mit meiner Mathematik? (Fragen in Fettdruck verstreuten diesen Beitrag)

Jede Hilfe wird geschätzt. Ich kann zwar nicht abschätzen, was los ist, erwäge jedoch ernsthaft, ext4 zugunsten von NTFS für alles außer meiner / -Partition aufzugeben.

Vielen Dank!

Hier ist einiges los. gparted meldet den aktuell genutzten / freien Speicherplatz. Der Kernel reduziert die verfügbare Anzahl um den reservierten Platz. Nachdem Sie den reservierten Speicherplatz entfernt haben, hat sich die Anzahl der freien Blöcke nicht geändert, da die reservierten Blöcke bereits frei waren. Es ist nur so, dass Nicht-Root-Benutzer nicht in diesen Bereich eindringen dürfen, um zu verhindern, dass sie Probleme verursachen, indem sie die Festplatte füllen. Die Gnomenzahlen sind aufgrund eines Fehlers etwas flockig . Anstatt den belegten Speicherplatz zu melden, den der Kernel meldet (und df anzeigt), berechnet er ihn, indem er den freien Speicherplatz von der Gesamtsumme subtrahiert. Dadurch wird reservierter Speicherplatz als verwendet angezeigt.

Die fehlenden 4GB werden tatsächlich verwendet, ist der fs-Overhead für ext4. NTFS weist der MFT zunächst nur wenig Speicherplatz zu und erweitert sie nach Bedarf. Die ext-Reihe von Dateisystemen weist der Inode-Tabelle jedoch zum Formatierungszeitpunkt Speicherplatz zu (ungefähr das Äquivalent der MFT), und sie kann nicht wachsen. Der im gemeldeten Gesamtspeicherplatz fehlende Speicherplatz ist die Inode-Tabelle. Der verbleibende belegte Speicherplatz stammt aus dem Journal (normalerweise 128 MB) und ändert die Größe der Inodes.

Zunächst werden reservierte Blöcke nicht für die interne Verwaltung des Dateisystems verwendet.

Reservierte Blöcke sind nur für reserviert root, um sicherzustellen, dass Dienste, die Dateien auf dieser Partition verwenden, nicht von Nicht-Administratoren ausgeschlossen werden können, die den gesamten Speicherplatz ausfüllen.

Selbst -m 0wenn keine reservierten Blöcke ( ) vorhanden sind, wird immer ein Teil des Speicherplatzes für die interne Verwaltung des Dateisystems verwendet. Ich kann nicht sagen, wie viel, ich habe kein so tiefes Wissen.

Außerdem wird Gparted als ausgeführt root, sodass reservierte Blöcke als frei angezeigt werden . Nautilus , als Benutzer ausgeführt, betrachten sie als nicht frei.

Ok, @psusi Antwort ist sehr klar, ich habe nichts hinzuzufügen.

Versuchen Sie, die Partitionsgröße mit gparted um einige Megabyte zu verringern und sie dann wieder auf die ursprüngliche Größe zu erhöhen. Dies kann dazu führen, dass andere Anwendungen die Größen korrekt lesen. Ich habe kürzlich einen 50-GB-Fehler auf diese Weise korrigiert!