Gleichzeitiges kopieren von verschiedenen Festplatten auf NAS - Fragmentation?

[Paddii]

Hallo zusammen,

ich habe ein NAS mit FreeNAS mit 8 Platten im Z2. Da ich eine Festplatte hinzugefügt habe, muss ich den Raid nun leider neu aufbauen.

Jetzt stellt sich mir nur die Frage, ist es möglich von 3-4 (externen) Festplatten gleichzeitig die Daten aus das NAS zu kopieren, oder würden die Daten dadurch Fragmentieren? Theoretisch werden hier ja 3-4 verschiedene Streams gleichzeitig, und damit (Dateisystemtechnisch) hintereinander, kopiert? Oder stellt das kein Problem dar?

Wenn ich von 3 Platten gleichzeitig kopiere schaffe ich ~120Mb/s / Platte. Wenn ich nur eine kopiere sind es nur ~140Mb/s.

Nur da man ZFS nicht defragmentieren kann möchte ich hier ungern ein Risiko eingehen.

 

[desmoule]

Nein. Ausführlichere Erklärungen: https://de.wikibooks.org/wiki/ZFS_auf_Linux/_Fragmentierung

 

[Holt]

Wieso sollte ZFS keine Fragmentierung kennen? Mit zpool list kann man sich sogar anzeigen lassen wie stark die Fragmentierung ist. Ob beim Schreiben mit zwei Streams Fragmentierung auftritt, hängt vor allem davon ab ob vorab der nötige Platz für die jeweiligen Dateien reserviert wird oder ob diese während des Schreibvorgangs immer größer werden.

 

[desmoule]

Da Holt anscheinend eine schlechte Internetverbindung hat und den Link nicht anklicken kann:

"FRAG ist ein Maß dafür, wie fragmentiert der freie Platz in einem zpool ist, wie schwer ZFS arbeiten muss, um neue Daten in den Pool zu schreiben.
Wenige Prozente bedeuten, dass der freie Platz als langes, zusammenhängedes Segment beschrieben werden kann und ZFS wenig Mühe hat damit. Und umgekehrt.
FRAG sagt nichts darüber aus, wie stark fragmentiert die bereits geschriebenen Daten im Pool sind."

Ich schlage einen Browser vor der möglichst wenig Datenvolumen verbraucht, links2 oder so, dann kann auch Holt die Seite lesen. Ich verspreche: es lohnt sich.

 

[snaxilian]

@Paddii: Nur um dir Probleme in der Zukunft zu ersparen: Du hast ein Raid-Z2 mit 8 Platten, den Pool erzeugt und Daten abgelegt und jetzt hast du eine Platte hinzugefügt? Denn eine vdev kann man nachträglich nicht vergrößern und erweitern. Du hättest aktuell ein gestriptes Pool bestehend aus dem Z2 und einer Single Disk. Sollte diese Single Disk ausfallen, dann wäre der Pool hinüber. Oder hast du deine Daten gesichert, den Pool + vdev zerstört und ein neues Z2 mit 9 Disks angelegt, neuen Pool erzeugt und die Sicherung zurück gespielt?

 

[Paddii]

Erstmal danke für die Antworten!

@ snaxilian
Ich habe von 7 auf 8 Platten aufgestockt. Den Pool habe ich natürlich zerstört und neu aufgebaut. Daher jetzt auch das "Problem" mit dem wieder einspielen.


Wenn ich das richtig verstehe heißt das ja, dass ein 3-4 fachen kopieren eher nicht zu empfehlen wäre, da dadurch ja die Daten im Pool kreuz und quer verteilt werden.

Sagen wir mal die kopierten Daten von den Festplatten sind Festplatte A, B und C.

Bei mehreren gleichzeitigen Kopiervorgängen würden die Platten ja wahrscheinlich Stückchenweise so schreiben:

A-B-C-A-B-C-A-B-C

Bei nur einem Kopiervorgang wäre es dann ja:

A-A-A---B-B-B---C-C-C

Also prinzipiell deutlich "aufgeräumter". Kann natürlich auch sein das ich das vollkommen falsch verstanden habe.

 

[snaxilian]

Afaik reserviert ZFS direkt alle benötigten Blöcke bei einer Schreiboperation. Selbst wenn du die 3 Kopiervorgänge direkt hintereinander startest sollten die Daten im Pool als AAABBBCCC ankommen. Die Fragmentierung erolgt erst, wenn du diese geschriebenen Dateien mal veränderst, da eben CoW bedingt erst die neuen Blöcke geschrieben werden und dann die alten gelöscht. Der Pool an sich sollte so erst nach Änderungen fragmentieren.

Aber: Bedingt durch das Z2 hast du doch sowieso eine Fragmentierung pro Platte eben bedingt, dass die Daten zwar linear im Pool geschrieben werden, der Pool diese dann aber auf die 8 Platten verteilt sowie eben Parity. Die Köpfe müssen also sowieso hin- und her beim lesen.

Ich denke wir bewegen uns hier aber sowieso im homöopathischen Spheren und du machst dir viel zu viele Gedanken. Wenn du Angst vor Performance-Verlusten hast dann solltest deinen Pool nicht zu mehr als 80% füllen, mehr als eine vdev nutzen und im besten Fall nur mirrored vdevs nutzen.
Siehe desmoules Link: ZFS und auch andere Dateisysteme unter Linux haben so gut wie keine Tools zum defragmentieren weil dies einfach nicht notwendig ist. Das System kümmert sich selbst darum.

 

[Paddii]

Reserviert ZFS hier denn den kompletten Unfang an zu kopierenden Daten (Also zB: 1TB aus 1000 Dateien), oder nur jeweils für jede Datei? Dann müssten die Platten ja nach jedem Schreibvorgang ans andere Ende der Platte wechseln und wieder zurück. Nur dafür ist es eigentlich viel zu schnell mit 4x ~100Mb/s.

Mehrere vdevs wären halt was den Speicher angeht recht ineffizient. Das wären dann bestenfalls 2x (4x1TB) im Z1, was am Ende gefährlicher wäre, als 8x1TB im Z2.

Das einzelne Befüllen würde halt bestimmt 4-5 Tage dauern. Mit mehreren gleichzeitigen Streams geht es wahrscheinlich in 1-2 Tagen. Am Ende wären aber auch 5 Tage kein Problem, daher möchte ich nicht gleich mit einem schlechten Start anfangen :-)

 

[Holt]

Afaik reserviert ZFS direkt alle benötigten Blöcke bei einer Schreiboperation. Selbst wenn du die 3 Kopiervorgänge direkt hintereinander startest sollten die Daten im Pool als AAABBBCCC ankommen.

Wenn A für die Teile einer Datei stimmt und das Protokoll die Größe vorab mitteilt, aber wenn jedes A für eine Datei steht, dann wäre die nur möglich wenn das Netzwerk Protokoll vorab sogar noch über alle Dateien informiert.

 

[snaxilian]

Mehrere vdevs wären halt was den Speicher angeht recht ineffizient. Das wären dann bestenfalls 2x (4x1TB) im Z1, was am Ende gefährlicher wäre, als 8x1TB im Z2.

Das kommt halt immer darauf an wie viele Platten man hat, ob man erweitern will, usw. Da bei mehr als einer vdev jedoch die Zugriffe verteilt werden, erhöhst du damit automatisch die IOPS. Das geht zwar nicht unendlich linear aber schon recht gut.
Und was bedeutet schon Effizienz bzw. bezogen worauf? Kommt halt immer drauf an, was das Ziel sein soll. Ein reines Datengrab mit etwas Performance mit mieser/aufwendiger Möglichkeit der Erweiterung? Klar, dann reicht ein einzelnes Raidz2, entsprechend lange Rebuildzeiten natürlich und für eine Vergrößerung musst entweder die Daten temporär woanders hin migrieren oder für jede Platte in der vdev je erst eine HDD tauschen, resilver und dann nächste Platte.