Verschiebe-Prozess stoppen?

[Commerzpunk]

Hallo,

ich habe es schon 'drüben' bei meinen Freunden von Kodinerds gepostet, da ist aber noch Weihnachtsruhe. 😄

 

Daher frage ich hier auch nochmal:

 

ich habe mich in eine blöde Situation gebracht.

Über die freien Tage wollte ich mein Unraid bisschen aufräumen und anders organisieren, da ich ja auch einen Hardwarewechsel plane.

 

Ich habe 1 x 12 TB Parity und 2 x 10 TB SATA. Glücklicherweise insgesamt 9.5 TB belegt.

 

Also wollte ich von der ZFS Integration profitieren und gleichzeitig die BTRF Verschlüsselung loswerden, irgendwie brauche ich das gefühlt nicht mehr.

 

Also alle Container und so gestoppt und auf die eine Platte verschoben, mit Unbalance.

Ging ganz gut, 1 Tag war alles fertig.

Die geräumte Platte aus dem Array raus, mit ZFS formatiert und wieder ins Array gepackt.

 

Jetzt wollte ich eigentlich nur das geiche Spiel mit der anderen Platte machen, vorher als die 9,5 TB auf die ZFS Platte verschieben.

 

Aus völlig unerklärlichen Gründen hatte Unbalance nun auf einmal den Haken bei dry run gesetzt und der Haken ist ausgegraut. Ich kann es einfach nicht mehr umschalten und in echt kopieren.

Also musste ich notgedrungen über den Filemanager von Unraid das Verschieben auf die andere Platte anstoßen.

Leider ist da was faul, das dauert bereits seit 3 Tagen und erst 1,5 TB verschoben.

In dem Popup vom Filemanager habe ich heute morgen schon "cancel" gedrückt, das Fenster ist auch weg, aber die Platten machen munter weiter.

CPU zeigt ordentlich Auslastung und die Platten haben Read / Write incl. Parity.

 

Wie kann ich das wieder unter Kontrolle bekommen, ohne wahrscheinlich 10 Tage zu warten?

 

 

--- --- ---

 

Mittlerweile habe ich in der Config Datei von Unbalance den Schalter für Dry run manuell auf false gesetzt und könnte es wieder verwenden.

Ebenfalls habe ich die Prozesse gefunden:

 

 

Hat jemand mit den Infos einen Tipp wie ich aus der Warteschlange komme? ☺️

 

[MAM59]

44 minutes ago, Commerzpunk said:

Wie kann ich das wieder unter Kontrolle bekommen, ohne wahrscheinlich 10 Tage zu warten?

Indem Du ZFS wieder rausschmeisst 🙂

ZFS im Array ist der große Fehler von 2023

So langsam kann kein alter Hund vor sich herschleichen.

 

Nein, ohne Pfrotzeln: UNRAID und "ZFS im Array" vertragen sich nicht. ZFS optimiert immer etwas rum (was ja nicht schlecht ist), weiß aber nix von der UNRAID Paritätsplatte. Dadurch gehen die "Optimierungen" voll nach hinten los und die Platten kommen aus dem Steppen nicht mehr raus. Das führt zu Transferaten von weniger als 70Mb/s (im günstigsten Falle, manche berichten von 20Mb/s und noch weniger). Soviel Lebenszeit haben die meisten nicht übrig.

Und selbst wenn Du die Orgie jetzt aussitzt, es wird später nicht besser!

 

ZFS funktioniert im Moment nur in einem Pool halbwegs ordentlich (sagen die meisten, meine Versuche waren hier auch sehr deprimierend, ich hab ZFS komplett verbannt inzwischen)

 

Also, Du wirst die 10 Tage abwarten und dann nochmals 10 Tage einplanen für den Rücktransfer.

 

[Commerzpunk]

Okay, krass, vielen Dank!

 

Unverständlich, warum bei Unraid in den Blogs und in Videos, die ich gesehen habe, die ZFS Implementierung als der nächste riesige Fortschritt propagiert wird.

 

Ich hatte sogar mal einen Beitrag gelesen, der das klassische Array und einen ZFS Pool gegenüber gestellt hat.

Ergebnis war: ZFS Pool ist genial super, hat aber den Nachteil, dass immer alle Platten laufen (oder nicht), es auf jeden Fall keinen Spindown einzelner Platten gibt.

Als Tipp wurde da gegeben, ein klassisches Array mit ZFS formatierten Platten zu nutzen - das war dann wohl doch nicht so schlau. 🙃

 

Gut, noch eine Frage:

 

Unbalance erfordert ja in den Voraussetzungen alle Docker und VMs sowie den Mover zu stoppen.

Aus Unsicherheit habe ich das nun auch für den Move Prozess gemacht.

 

Mittlerweile nervt mich aber, dass ich keine Dienste und so mehr hab.

Kann ich die starten? Oder was ist hier eine gute Empfehlung?

 

Wenn der Transfer erst mal durch ist, kann ich gut mit den langsamen Raten leben, ist ja eher ein typisches Daten- / Medien Archiv.

 

Dann warte ich eher, bis nochmal ein Plattenwechsel ansteht oder so.

 

 

[DataCollector]

2 hours ago, Commerzpunk said:

Okay, krass, vielen Dank!

 

Unverständlich, warum bei Unraid in den Blogs und in Videos, die ich gesehen habe, die ZFS Implementierung als der nächste riesige Fortschritt propagiert wird.

 

Weil zfs im Pool mit mehr als 1 Datenträger sehr viel Sinn macht. Nur eben nicht im Array!

Im Array ist xfs sehr sinnvoll.

 

2 hours ago, Commerzpunk said:

Ich hatte sogar mal einen Beitrag gelesen, der das klassische Array und einen ZFS Pool gegenüber gestellt hat.

 

Diese Gegenueberstellung macht ja auch sinn, da beide das zusammenfassen von mehreren Datenträgern ermöglichen.

Array hat aber die Vorteile, daß nicht benötigte Festplatten weiter schlafen können und den Nachteil, dass das Array langsam ist.

Dafür hat ein zfs Pool den Nachteil, daß imme ralle Festplatten laufen müssen, wen Dateien gelesen/geschrieben werden und den Vorteil daß der pool sehr schnell ist.

 

Aber zfs im Pool hat eben eher wenig Sinn.

Nur, wenn man snapshots machen will und auch die Parität verzichtet sehe ich eine Sinn (und auch Nutzen) von zfs im Array.

Aber das ist wohl eher weniger der übliche Anwendungszwecj des unarid Array.

 

2 hours ago, Commerzpunk said:

Ergebnis war: ZFS Pool ist genial super, hat aber den Nachteil, dass immer alle Platten laufen (oder nicht), es auf jeden Fall keinen Spindown einzelner Platten gibt.

 

Ja, deshalb ist es ja auch im (kleinen) Pool einzusetzen.

Wenn ich ein Array aus 28 Datenfestplatten und 1 oder 2 Parity mache wird der stromspareffekt sehr groß: Es laufen beim Lesen/schreiben einer Datei eben nur 1 bis 3 Festplatten gleichzeitig.

Wenn man einen zfs Pool mit 30 Fesplatten aufmacht laufen dann bei lese/schreibzugriff immer alle 30 Festplatten= riesiger Dauerstromverbrauch.

Deshalb besser zfs in kleinen (SSD) Pools einsetzen und im Array bevorzugt normales Dateisystem (ich bevorzuge xfs).

 

2 hours ago, Commerzpunk said:

Unbalance erfordert ja in den Voraussetzungen alle Docker und VMs sowie den Mover zu stoppen.

 

Ich nutze sowieso kein unbalance. Mit mc oder krusader bilde ich mir ein die Sache für mich besser und übersichtlicher im Griff zu haben.

Docker, VM und Array können dabei normal weiter laufen und das System bleibt nutzbar/erreichbar.

 

[Commerzpunk]

Okay, vielen Dank für die Antworten, ich werde dann irgendwann wieder auf xfs wechseln.

 

Folgende Fragen sind noch offen:

 

1. Muss ich jetzt alles runtergefahren lassen und die x Tage abwarten?

 

2. Krusader finde ich auch gut, hatte aber immer gedacht alles was sich außerhalb der /user/user Shares liegt, also was sich außerhalb der Array Logik abspielt, halt direkt Disk auf Disk, sollte man eben nicht machen? Wie ist denn hier die Empfehlung?

[alturismo]

49 minutes ago, Commerzpunk said:

2. Krusader finde ich auch gut, hatte aber immer gedacht alles was sich außerhalb der /user/user Shares liegt, also was sich außerhalb der Array Logik abspielt, halt direkt Disk auf Disk, sollte man eben nicht machen? Wie ist denn hier die Empfehlung?

 

wenn du weißt was du machst ... alles gut. unbalance macht im Grunde nichts anderes ... nur automatisiert ...

 

zu zfs, sag ich nichts ... steht alles oben.

[Commerzpunk]

Okay, danke. Könntest du, oder jemand anderes, etwas konkreter werden?

 

Ich habe immer noch die offene Frage:

 

1. Muss ich jetzt alles (die Docker und VM) runtergefahren lassen und die x Tage abwarten?
 

2. Wie ist denn eine konkrete Empfehlung, wenn ich im laufenden Betrieb Daten von Platte 1 auf Platte 2 im Array verlagern möchte? Also praktisch die Verteilung auf den physischen Platten ändern, während in den virtuellen Shares alles gleiche bleibt?

 

Danke euch

[DataCollector]

24 minutes ago, Commerzpunk said:

1. Muss ich jetzt alles (die Docker und VM) runtergefahren lassen und die x Tage abwarten?

 

Da ich unbalance nicht nutze kann ich dazu nichts sagen.

Frag vielleicht mal im Support des Tools nach.

 

24 minutes ago, Commerzpunk said:

2. Wie ist denn eine konkrete Empfehlung, wenn ich im laufenden Betrieb Daten von Platte 1 auf Platte 2 im Array verlagern möchte?

Wie erwähnt nehme ich mc.

 

Also mc starten auf beiden Seiten in mnt einsteiegen und dann kann man auf der einen Seite die Quelldisk auswählen und dort bis zu der gewünschten Datei/Verzeichnis gehen udn auf der anderen Seite das Selbe mit dem Zielverzeichnis.

Und dann drücke ich F6 und lasse den mc dann verschieben.

Siehe beiliegenden Screenshot von mc.

Das Verschieben großer Datenmengen (Verzeichnisse) gerät (je nach Cachegröße) ab und zu ins Stocken und auf dem Quelllaufwerk löscht er erst, wenn das ganze Verzeichnis kopiert wurde. (Achja, und seit unraid 6.1y.x scheint der mc keine Fortschrittsbalken mehr anzuzeigen. Ein nerviger Schönheitsfehler, aber damit kann ich leben.)

Zu Deutsch: etwas Geduld ist bei Kopier-/Verschiebeaktionen notwendig.

 

Nebenbei: mit dem Plugin Dynamix Filemanager kann man auch im laufenden Prozeß gut verschieben, aber mir ist das zuviel Mouseklickerei.

 

Im Screenshot:

gelb markiert die Quelle, 

grün markiert Ziel

pink der Verschiebebefehl

 

Ähnlich geht es auch mit dem Docker "krusader".

 

 

24 minutes ago, Commerzpunk said:

Also praktisch die Verteilung auf den physischen Platten ändern, während in den virtuellen Shares alles gleiche bleibt?

Ja, genau das.

 

[Commerzpunk]

Okay, ich glaube dann verstehen wir uns die ganze Zeit irgendwie falsch.

 

Ich benutzt ja gar kein Unbalance, ich wollte, aber es ging ja nicht. Meine aktuellen Verschiebe-Prozesse, siehe oben, sind über den Dynamix File Manager gestartet, und zwar von Disk1 zu Disk3.

 

Wahrscheinlich hatte ich mir mal was falsch im Kopf abgespeichert, ich dachte immer man soll Unraid keinesfalls auf den Platten rumpfuschen, weil das beim Speichern und Ändern von Dateien im Laufenden System das Array durcheinander bringt, weil Unraid ja ne eigenen Logik hat.

 

Ergo, ich könnte die Docker und VMs einfach hochfahren und lasse es weiter kopieren?

Wenn ich dann wieder auf xfs umsteige, kann ich das dann ebenso im Hintergrund von disk zu disk kopieren, mit mc, krusader oder sonst was?

 

Wäre wesentlich entspannter als ich das abgespeichert hatte.

[alturismo]

26 minutes ago, Commerzpunk said:

Wenn ich dann wieder auf xfs umsteige, kann ich das dann ebenso im Hintergrund von disk zu disk kopieren, mit mc, krusader oder sonst was?

 

ich wiederhole mich nur ungern, aber ja ... 

 

19 hours ago, alturismo said:

wenn du weißt was du machst ... alles gut. unbalance macht im Grunde nichts anderes ... nur automatisiert ...

 

 

mv /mnt/cache <> /mnt/diskX

mv /mnt/diskX <-> /mnt/cache

mv /mnt/diskX <> /mnt/diskX

 

alles gut ...

---

mv /mnt/user/.... <> /mnt/diskX/

mv /mnt/user/ <> /mnt/cache/

 

NICHT alles gut ... weil es viele viele gibt die das machen ... von user Share zu diskX/cache ... und dann knallt es gerne, daher nicht empfohlen.

---

 

was du am Ende dafür benutzt, such Dir was aus

 

Terminal direkt, mc, File Manager, Plugins wie unbalance, Docker wie Krusader, Disk Shares von einem PC Client aus, .... so wie es DIR gefällt, gehen tut alles, nur die Regel beachten NICHT von/zu User Shares von/zu disks direkt ...

 

und das hat nichts mit konstruktiv zu tun, nicht konstruktiv wäre, geh dorthin wo du den Kram zu zfs gelesen / gesehen hast und frag da nach ... hier steht nirgends das zfs im Array empfohlen ist ... nur 1000+ Fragen weil es nicht läuft wie erwartet ... was auch klar ist wenn man kurz nachliest ... egal

 

Schöne Weihnachten noch.

[Commerzpunk]

Ja, ich lerne da auch gern dazu, Unraid muss man ja auch irgendwie bisschen kennenlernen.

 

@alturismo Ich verstehe nicht, was du mit konstruktiv / nicht konstruktiv meinst, ehrlich gesagt.

 

Wo ich den Kram zu ZFS gelesen habe, war hier:

https://unraid.net/blog/zfs-guide

 

Zitat / Auszug:

 

Quote

Hybrid Approach

ZFS-formatted disks within the Unraid array

Pros:

This strategy combines Unraid's array flexibility, allowing for easy capacity expansion, and ZFS's advanced features, such as data compression and snapshots.

 

Klingt für mich tatsächlich nach einer Empfehlung, natürlich kommen da noch Contra Punkte, aber abgeraten wird keinesfalls.

 

Und weil das ein offizieller Unraid Artikel ist, dachte mir natürlich das PRO, die Flexibilität des Arrays und die Erweiterten Funktionen von ZFS, nehme ich!

 

 

 

Edited December 26, 2023 by Commerzpunk

[alturismo]

13 minutes ago, Commerzpunk said:

Wo ich den Kram zu ZFS gelesen habe, war hier:

https://unraid.net/blog/zfs-guide

 

Zitat / Auszug:

 

Mann Mann ... Danke für den Wink

 

das werde ich mal weiterleiten was man sich dabei denkt ... Urgs.

 

mea cul·pa

[DataCollector]

10 hours ago, Commerzpunk said:

Okay, ich glaube dann verstehen wir uns die ganze Zeit irgendwie falsch.

 

Sorry, ich dachte Du hättest unbalance gestartet. Vermutlich war es mein Verständnisfehler.

 

10 hours ago, Commerzpunk said:

Ich benutzt ja gar kein Unbalance, ich wollte, aber es ging ja nicht. Meine aktuellen Verschiebe-Prozesse, siehe oben, sind über den Dynamix File Manager gestartet, und zwar von Disk1 zu Disk3.

 

Der Dynamix File Manager ist doch ein Plugin. Plugins laufen bei aktivem Array super. Ich habe es gerade mal ausprobier. Wnen das Array getsoppt ist, kann ich den DFM gar nicht aufrufen/benutzen.

Noch schlimmer. Solltest Du in Deinem Array eine (oder gar 2) Paritydisks nutzen, würdest Du bei gestopptem Array zwischen den Platten verschieben, ohne daß es die Parity mitbekommt, wodurch die Parity dann unbrauchbar würde und am Ende neu erstellt werden müsste.

 

10 hours ago, Commerzpunk said:

Wahrscheinlich hatte ich mir mal was falsch im Kopf abgespeichert, ich dachte immer man soll Unraid keinesfalls auf den Platten rumpfuschen, weil das beim Speichern und Ändern von Dateien im Laufenden System das Array durcheinander bringt, weil Unraid ja ne eigenen Logik hat.

 

Also bei unraid darf man bei laufendem Array mit den Tools zwischen den Disks hin und her kopieren/verschieben/löschen.

Es ist nur wegen der ständigen Parityzugriffe eben recht langsam.

Man darf bei unraid im Array nur nicht von Disk auf Share oder umgekehrt verschieben, da man sich ggf. die Dateien unter dem Hintern wegzieht oder ggf, Doubletten an unterschiedlichen Stellen erstellt.

Un dja, all das sollte (bei vorhanderer Parity) immer bei laufendem/gestarteten Array stattfinden, damit unraid eben die Parity aktuell halten kann.

Natürlich belastet das die Arrayplatten sehr, weshalb andere Operationen (SMB Zugriffe oder so) auf das Array massiv gebremst werden.

 

 

 

10 hours ago, Commerzpunk said:

Ergo, ich könnte die Docker und VMs einfach hochfahren und lasse es weiter kopieren?

 

Klar.

Ich gehe mal davon aus, das Deien Docker und VM sowieso primär auf einer Pool SSD und nicht auf den Array Festplatten laufen.

 

10 hours ago, Commerzpunk said:

Wenn ich dann wieder auf xfs umsteige, kann ich das dann ebenso im Hintergrund von disk zu disk kopieren, mit mc, krusader oder sonst was?

 

ob xfs, btrfs oder zfs ist dabei egal. Hauptsache die Disks sind eben alles Einzeldisks udn keine Raidverbünde in einem Pool.

Bei einem zfs/btrfs Raid zu versuchen irgendetwas auf einer der einzeldisks zu machen kann zu totalem Datenverlust führen, wäre aber auch nicht mit den bisher benannten Tools möglich.

 

Edited December 26, 2023 by DataCollector

[DataCollector]

On 12/26/2023 at 2:11 PM, Commerzpunk said:

Wo ich den Kram zu ZFS gelesen habe, war hier:

https://unraid.net/blog/zfs-guide

...

Klingt für mich tatsächlich nach einer Empfehlung, natürlich kommen da noch Contra Punkte, aber abgeraten wird keinesfalls.

Das ist keine Empfehlung, sondern eine Auflistung

Wenn man Snapshots braucht: ja, dann ist zfs brauchbar, belastet aber die Parityfestplatte zusätzlich, wenn die Änderungen dann irgendewann geschrieben werden.

Wenn man Datenkompresion braucht, kann man das machen. Bringt aber nur etwas bei Dateien, die sich wirklich verlustlos recht gut komprimieren lassen, sonst frißt es primär Rechenpower um es eben zu versuchen, bringt aber vielleicht nur wenigste Prozent Platzersparnis.

 

Die eigentlich (in meinen Augen) sinnvolle Anwendung von zfs ist es die Möglichkeit eine Art Raid über mehrere Disks aufzubauen. Doch genau das geht im Array eben nicht.

Das geht im pool und dort sehe ich (!!rein subjektive Meinung!!) dann als sinnvoll an.

Edited January 2 by DataCollector

[Commerzpunk]

Ja, wenn man meine Worte und die aus dem Artikel auf die Goldwaage legt, ist das keine Empfehlung, das stimmt.

Die Formulierung "This strategy combines Unraid's array flexibility, allowing for easy capacity expansion, and ZFS's advanced features" klingt halt sehr positiv.

 

Vielleicht liegt es an meinem System, es ist aber ein potenter i5 der 8. Generation mit 32 GB RAM und 3 je 3 Jahre alten SATA Platten.

 

Aber ich habe das Chaos nun durch und es hat ~14 Tage gedauert die 10 TB zu verschieben.

Das ist so unterirdisch schlecht, dass ich eine deutlichere Warnung bei den Contras erwarte!

 

Das zurück Verschieben auf die neu formatierte XFS Platte geht nun mit normaler Geschwindigkeit, ca. 3 TB je 24h.

[Commerzpunk]

Ich denke, es gibt doch eine andere Erklärung:

Es könnte ein Bug in dem eingebauten Filemanager sein.

Ich habe bisher die 3 großen Verzeichnisse mit z. B. Filmen oder ISOs jeweils einzeln verschoben, das ging schön schnell.

Jetzt hatte ich mehrere Verzeichnisse mit vielen kleinen Dateien drin, Fotos, Dokumente und so - diese habe ich alle in einem Rutsch ausgewählt und verschoben:

 

 

Das sind jetzt 8 Verzeichnisse.

Die Geschwindigkeit ist wieder extrem bescheiden, ich habe mal mit htop nachgeschaut und nach rsync gefiltert:

 

Für mich sieht das so aus, als ob der Filemanager je Verzeichnis einen eigenen Befehl absetzt, in dem auch je alle Verzeichnisse enthalten sind. (+ 1 für das Ziel = 9 Prozesse für 8 Quellen und 1 Ziel).

 

Wenn man nach rechts scrollt sieht man das, es ist exakt der gleiche Befehl der jeweils alle im oben Screenshot gewählten Verzeichnisse in einer Reihe hat, und dann als letztes Argument nochmal das Ziel (/mnt/disk1/).

 

Das bedeutet doch, dass die Befehle praktisch gegeneinander kämpfen und die Sache immer langsamer machen, oder? 

 

 

 

[hawihoney]

20 minutes ago, Commerzpunk said:

Das bedeutet doch, dass die Befehle praktisch gegeneinander kämpfen und die Sache immer langsamer mac

 

@bonienl Can you please have a look at that htop shown above. Is it intended behaviour that multiple directories are copied/moved by multiple processes in parallel - even when copying/moving to the same target?

 

[hawihoney]

30 minutes ago, Commerzpunk said:

Das bedeutet doch, dass die Befehle praktisch gegeneinander kämpfen und die Sache immer langsamer machen, oder? 

 

Kannst Du das mal mit lsof gegen checken? Sind die Dateien auf dem Ziel alle gleichzeitig offen?

 

[Commerzpunk]

Hallo,

ich kenne mich mit Linux und den Befehlen nur wenig aus, ich hoffe, ich habe es richtig gemacht:

 

 

 

Es sind auf jeden Fall die 9 rsync Prozesse am Werk, aber die Dateien sind, wie man trotz Verpixelung wohl sehen kann, alle unterschiedlich.

 

Im Ergebnis sind die Übertragungsraten dadurch halt übelst langsam.

 

[hawihoney]

1 hour ago, Commerzpunk said:

Es sind auf jeden Fall die 9 rsync Prozesse am Werk

 

Die cwd (change working directory) DIR zählen nicht. Der shfs kümmert sich um etwas anderes. Bleiben 3 rsync  Einträge übrig. Drei aufeinander folgende Nodes. Hmm.

 

Da muss boniel mal drauf gucken. Im Moment würde ich sagen ist ok so.

 

Ich nutze zum umfangreichen Kopieren/Verschieben eigentlich immer mc in einer screen Session. DFM nutze ich überwiegend nur um mal eben schnell etwas zu löschen.

 

Kannst Dir spaßeshalber die Zeitstempel der betreffenden Dateien auf disk1 anschauen. Verändern die sich alle oder nur einer?

 

Edited January 2 by hawihoney

[Commerzpunk]

Es ändern sich, sofern ich das mit meinen begrenzten Mitteln rausfinden konnte, die Zeitstempel der Dateien mit . vornedran. Sind das Temp Dateien? Die haben auch alle so seltsame Buchstaben am Ende .5t9HlO usw.

 

Ich habe den Befehl ls -a -l in einem Unterverzeichnis genutzt in dem große Backup-HDD Images reinlaufen sollten.

 

Eine Datei, die keinen Punkt hat, aber von lsof angezeigt wird, zeigt aber z. B. keine Änderung des Zeitstempels.

 

Was sagt mir das nun? Warum kopiert (verschiebt) es so extrem lahm?

[DataCollector]

38 minutes ago, Commerzpunk said:

Was sagt mir das nun? Warum kopiert (verschiebt) es so extrem lahm?

 

Ich kann nur vermuten:

Sollte Deine Ansicht stimmen und mehrere Prozesse gleichzeitig mehrere Dateien auf Festplatten im Array schreiben wollen (egal ob es die selbe Datenfestplatte oder mehrere sind)

sind das natürlich bremsende Faktoren durch die sehr heftigen Kopfbewegungen beim Schreiben einerseits auf den Array Datenfestplatten, aber wenn da eine oder 2 Parity noch beteiligt sind, die diese Kopfbewegungen auch noch gleichzeitig mitmachen müssen (und dazu ihr bremsendes Lese, Korrektur, warte auf Sektor, Schreibe) Verhalten haben, bremst Du mit beispielsweise 3 gleichzeitig zu schreibenden Dateien auf der Datenfestplatte über die Parity auf 1/3 der sonstigen Arrayleistung herunter,

weil die Köpfe der Parity eben noch viel mehr hin und her flitzen müssen um dann dort auf den jeweiligen Sektor zu warten.

 

(Puh, war das ein langer Satz! 😅 )

 

In einem Array mit Parity sehe ich absolut keinen Vorteil darin mehrere Schreibprozesse gleichzeitig im Array durchzuführen, weil sich alles an der Parity in die Quere kommt und somit zusätzliche Wartezeiten auftreten.

Ich erwähnte schon mehrfach: ich kopiere/verschiebe zwischen den Disks im Array per mc oder krusader, welche das dann sequentiell hintereinander machen (können). (also so, wie es auch hawihoney schreib)

Dann bremst sich das nicht wirklich noch extra an der Parity aus.

Edited January 2 by DataCollector