Multitasking, Kopieren und Fragmentierung in Linux

[Besorgter Benutzer (Gast)]

Ist es gängige Praxis zu kopieren wie in Abb. 1 oder sieht der Profi 
sich wegen Fragmentierungsgefahr vor? Lässt sich in Debian GNU/Linux 11 
untersuchen ob das Ergebnis auf fat und ext Dateisystemen eher Abb. 2 
(a) oder (b) gleicht?

Abb. 1: POSIX Shellskript. A und B seien jeweils größere Dateien, C ein 
Verzeichnis.

#!/bin/sh
cp -a $A $C &
cp -a $B $C

Abb. 2: Vereinfachte Sektordarstellungen des Verzeichnisses C nach 
Abschluss der Kopiervorgänge, in (a) ohne, in (b) mit Fragmentierung.

+-------+      +-+-+-+-+
| A | B | oder |A|B|A|B|
+-------+      +-+-+-+-+
   (a)            (b)

[(prx) A. K. (prx)]

Zwischen Theorie und Praxis können gerade in solchen Fragen Welten 
liegen, denn ob sich das Filesystem so verhält, wie die Frage 
impliziert, würde ich nicht als gegeben ansehen. Manchmal kennen 
Filesystem-Coder solche Effekte und beugen vor.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Besorgter Benutzer schrieb:
> Ist es gängige Praxis zu kopieren wie in Abb. 1 oder sieht der Profi
> sich wegen Fragmentierungsgefahr vor?

Nein.

Der Profi verläßt sich darauf, dass die Kernelentwickler 
Fragmentierungsprobleme seit 30 Jahren kennen und im Laufe der Zeit 
besser optimiert haben als man es selbst je könnte. Daher besteht ein 
viel zu hohes Risiko, dass man es schlechter macht weil man glaubt es 
durch Tricks besser machen zu können.

> Lässt sich in Debian GNU/Linux 11
> untersuchen ob das Ergebnis auf fat und ext Dateisystemen eher Abb. 2
> (a) oder (b) gleicht?

Weder noch.

Die Filesystem-Treiber (z.B. ext4) optimieren wohin Blöcke geschrieben 
werden und benutzen auch von vorangegangenen Löschvorgängen entstandene 
Lücken, so dass das Ergebnis nicht vorhersagbar ist und bei 2 
Durchläufen völlig unterschiedlich aussehen kann.

Ausserdem unterstellst Du dass die beiden Prozesse immer schön 
abwechselnd je 50% Rechen- und I/O Zeit zugeteilt bekommen sonst 
entsteht kein a/b/a/b-Muster.

Da die Summe der I/O-Zeiten konstant ist, kann man auch einfach die 
beiden Files nacheinander ins Verzeichnis C kopieren: cp -a $A $B $C/

Schließlich: untersuchen kann man das indem man das Filesystem auf dem 
Raw-Device byteweise anschaut und decodiert... Z.B. kann man eine 
Testdatei $A mit 2 GByte 0xaa schreiben und eine $B mit 0xbb schreiben 
und dann schauen wo die Sektoren liegen.

Schließlich: wenn man eine SSD verwendet ist es völlig egal wo die 
Sektoren/Blöcke auf dem Raw-Device liegen. Jeder ist gleich schnell 
wieder lesbar.

[Dergute W. (derguteweka)]

Besorgter Benutzer schrieb:
> Lässt sich in Debian GNU/Linux 11
> untersuchen ob das Ergebnis auf fat und ext Dateisystemen eher Abb. 2
> (a) oder (b) gleicht?

Warum sollte das nicht gehen?
Kannst dir ja mal per loopdevice ein extX oder sonstein Filesystem 
deiner Geschmacksrichtung in ein File einbauen; das dann mounten, per 
deinen cp commands die Dateien reinschreiben; wieder umounten und dann 
in dem File mit dem Filesystem drinnen angucken, wie da die Daten so 
rumoxidieren.

Gruss
WK

[The Allocator (Gast)]

https://opensource.com/article/18/4/ext4-filesystem

Und dann nach "allocation" suchen.

[(prx) A. K. (prx)]

Nikolaus S. schrieb:
> Da die Summe der I/O-Zeiten konstant ist

Auch darauf würde ich nicht wetten. Parallele I/O kann bei heutigen 
Medien deutlich schneller sein als die Summe der einzelnen I/Os.

[PittyJ (Gast)]

Seitdem wir keine rotierenden Scheiben mehr benutzen, ist das alles 
irrelevant.

Bestimmt wieder so ein TE, der wirre Diskussionen auslösen möchte. So 
wie letztens der Diskettentyp.

[(prx) A. K. (prx)]

PittyJ schrieb:
> Bestimmt wieder so ein TE, der wirre Diskussionen auslösen möchte. So
> wie letztens der Diskettentyp.

Klingt eher nach Hausaufgabe.

[Walter der Hirnchirurg (Gast)]

Hausaufgabe

[Besorgter Benutzer (Gast)]

The Allocator schrieb:
> https://opensource.com/article/18/4/ext4-filesystem
>
> Und dann nach "allocation" suchen.

Danke, dass war sehr interessant.

Die folgenden Absätze aus dem Artikel

"Ext3 called its block allocator once for each new block allocated. This 
could easily result in heavy fragmentation when multiple writers are 
open concurrently. However, ext4 uses delayed allocation, which allows 
it to coalesce writes and make better decisions about how to allocate 
blocks for the writes it has not yet committed."

und

"Although ext3 was originally deemed 'unaffected by fragmentation,' 
processes that employ massively parallel write processes to the same 
file (e.g., BitTorrent) made it clear that this wasn't entirely the 
case. Several userspace hacks and workarounds, such as Shake, addressed 
this in one way or another—but they were slower and in various ways less 
satisfactory than a true, filesystem-aware, kernel-level defrag 
process."

sagen eigentlich alles.

[Hermann Kokoschka (Gast)]

Um WELCHEN MIKROCONTROLLER geht es denn genau..?

[rbx (Gast)]

Hermann Kokoschka schrieb:
> Um WELCHEN MIKROCONTROLLER geht es denn genau..?

Stimmt, Filesystemfragen/schnelle Filesysteme sind (H)PC-spezifisch.

Parallelprogrammierung nicht unbedingt, aber darum geht es ja hier auch 
nicht.