Warum sind diese Dateien in einem ext4-Volume fragmentiert?

Ich habe eine 900-GB- ext4Partition auf einer (magnetischen) Festplatte, die keine Defekte und keine fehlerhaften Sektoren aufweist. Die Partition ist bis auf ein leeres lost+foundVerzeichnis vollständig leer . Die Partition wurde mit Standardparametern formatiert, mit der Ausnahme, dass ich die Anzahl der reservierten Dateisystemblöcke auf 1% festgelegt habe.

Ich habe die ~ 900MB-Datei mit xubuntu-15.04-desktop-amd64.isoin das Mount-Point-Verzeichnis der Partition geladen wget. Als der Download beendet war, stellte ich fest, dass die Datei in vier Fragmente aufgeteilt war:

filefrag -v /media/emma/red/xubuntu-15.04-desktop-amd64.iso
Filesystem type is: ef53
File size of /media/emma/red/xubuntu-15.04-desktop-amd64.iso is 1009778688 (246528 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  190463:     198656..    229375:  30720:            
   6:   190464..  223231:     231424..    264191:  32768:     229376:
   7:   223232..  246527:     264192..    287487:  23296:             eof
/media/emma/red/xubuntu-15.04-desktop-amd64.iso: 4 extents found

Da ich dachte, dies könnte sich wgetirgendwie ändern , entfernte ich die ISO-Datei von der Partition und machte sie wieder leer. Dann kopierte ich die ~ 700MB-Datei mit v1.mp4auf die Partition cp. Diese Datei wurde ebenfalls fragmentiert. Es wurde in drei Fragmente aufgeteilt:

filefrag -v /media/emma/red/v1.mp4
Filesystem type is: ef53
File size of /media/emma/red/v1.mp4 is 737904458 (180153 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  180152:     198656..    219064:  20409:             eof
/media/emma/red/v1.mp4: 3 extents found

Warum passiert das? Und gibt es eine Möglichkeit, dies zu verhindern? Ich dachte ext4, es sollte resistent gegen Fragmentierung sein. Stattdessen finde ich, dass es sofort eine einzelne Datei fragmentiert, wenn der Rest des Volumes nicht verwendet wird. Dies scheint schlimmer zu sein als beides FAT32und NTFS.

3 oder 4 Fragmente in einer 900-MB-Datei sind sehr gut. Fragmentierung wird zu einem Problem, wenn eine Datei dieser Größe mehr als 100 Fragmente enthält. Es ist nicht ungewöhnlich, dass fat oder ntfs eine solche Datei in mehrere hundert Teile fragmentieren.

In der Regel wird dies zumindest auf älteren ext4-Dateisystemen nicht besser angezeigt, da die maximale Größe einer Blockgruppe 128 MB beträgt. Daher wird der zusammenhängende Speicherplatz für die Zuordnungsbitmaps und Inode-Tabellen für die alle 128 MB von einigen Blöcken unterbrochen nächste Blockgruppe. Eine neuere ext4-Funktion mit dem Namen flex_bg ermöglicht das Zusammenpacken mehrerer (in der Regel 16) Blockgruppen dieser Tabellen. Je nach Distribution und der Version von e2fsprogs, die zum Formatieren verwendet wurde, bleibt eine längere Anzahl zuweisbarer Blöcke übrig nicht benutzt worden.

Mit können tune2fs -lSie die Funktionen überprüfen, die aktiviert waren, als Ihr Dateisystem formatiert wurde.

Ich kann nicht wirklich antworten, aber ich denke, das könnte helfen:

Beachten Sie, dass jedes Fragment höchstens 32768 Blöcke groß ist (eine Zweierpotenz, die ein Flag auslösen sollte, das auf etwas hinweist, und Ihnen auch einen Hinweis auf etwas gibt, nach dem Sie suchen müssen).

Erwähnenswert ist auch, dass diese physischen Offsets zwischen den Ausdehnungen ziemlich nahe beieinander liegen.

Von: Ext4-Festplattenlayout

Ein ext4-Dateisystem ist in eine Reihe von Blockgruppen aufgeteilt. Um Leistungsschwierigkeiten aufgrund von Fragmentierung zu verringern, versucht der Blockzuweiser, die Blöcke jeder Datei in derselben Gruppe zu halten, wodurch die Suchzeiten verringert werden. Die Größe einer Blockgruppe wird in angegeben sb.s_blocks_per_group blocks, kann aber auch mit 8 * berechnet werden block_size_in_bytes. Bei der Standardblockgröße von 4 KB enthält jede Gruppe 32.768 Blöcke mit einer Länge von 128 MB

Und weiter unten:

Das erste Tool, mit dem ext4 die Fragmentierung bekämpft, ist der Multi-Block-Allokator. Wenn eine Datei zum ersten Mal erstellt wird, weist der Blockzuweiser der Datei spekulativ 8 KB Speicherplatz zu. [...] Ein zweiter Trick, den ext4 verwendet, ist die verzögerte Zuweisung. Wenn nach diesem Schema eine Datei mehr Blöcke zum Absorbieren von Dateischreibvorgängen benötigt, verschiebt das Dateisystem die Entscheidung über die genaue Platzierung auf der Festplatte, bis alle fehlerhaften Puffer auf die Festplatte geschrieben wurden. Wenn Sie sich erst dann auf eine bestimmte Position festlegen, wenn dies unbedingt erforderlich ist (das Zeitlimit für das Festschreiben wurde überschritten oder sync () aufgerufen wurde oder der Kernel nicht mehr genügend Arbeitsspeicher hat), können Sie hoffen, dass das Dateisystem bessere Standortentscheidungen treffen kann.

Ich würde also sagen, der Allokator kümmert sich nur um die Datenlokalität innerhalb der Blockgruppe (diese 32-KByte-Blöcke), nicht aber darum, dass Blockgruppen aneinander angrenzen.