5 minutes ago, mgutt said:

😂

 

😅

Ich bin halt noch blutjunger Anfänger ^^

Jedenfalls danke für eure Geduld. 

 

17 minutes ago, hawihoney said:

 

Ja, auf Pause klicken.

 

 

Sorry, 

ich glaub ich seh den Wald vor lauter Bäumen nicht mehr.

Wo ist ein "Pause"-Button im Dashboard.? 

Naja unten wo steht das der Parity Check läuft.

31 minutes ago, Laho said:

Wo ist ein "Pause"-Button im Dashboard.?

 

Auf der Hauptseite sind die ganzen Buttons. Da haste das doch auch angeworfen, oder?

 

3 minutes ago, hawihoney said:

 

Auf der Hauptseite sind die ganzen Buttons. Da haste das doch auch angeworfen, oder?

 

 

Ahhhh.... 

Danke. Klar, man muss runter scrollen. Dort wo man das Array startet z.B.

Puhh, hab mich grad ausgezeichnet ^^

Danke auf jeden Fall!

1 hour ago, mgutt said:

😂

 

Leider zu gefreut. Parity Check ist pausiert. 

Kopiere gerade große MKV Files (ca. 3,10TB) auf ein Share - Gewschwindigkeit bricht ein auf 40-60mb, anfänglich wars wie gehabt 113.

 

Kurz davor hab ich so ca. 30GB  kopiert. Da hatte ich durchgehernd ca. 113-105mb (falls jemand mit der Info etwas anfangen kann.

 

 

 

Edited January 25, 20233 yr by Laho

2 hours ago, Laho said:

Gewschwindigkeit bricht ein auf 40-60mb

 

Das ist doch nix Ungewöhnliches im Parity-Protected Array. Das entspricht min. 120-180 MB/s. Am Anfang zieht der RAM-Cache. >100 MB/s bekommt man nicht bei Standard-Konfiguration mit Harddisks im Parity-Protected Array.

 

Ich muss mir mal ein paar Makros basteln für die immer und immer wieder gleichen Fragen. Oder besser gleich ein paar Youtube Videos 😁

 

Edited January 25, 20233 yr by hawihoney

2 hours ago, hawihoney said:

 

Das ist doch nix Ungewöhnliches im Parity-Protected Array. Das entspricht min. 120-180 MB/s. Am Anfang zieht der RAM-Cache. >100 MB/s bekommt man nicht bei Standard-Konfiguration mit Harddisks im Parity-Protected Array.

 

Ich muss mir mal ein paar Makros basteln für die immer und immer wieder gleichen Fragen. Oder besser gleich ein paar Youtube Videos 😁

 

 

Sorry ^^

Und ja Youtube Video wäre vermutlich perfekt 😅

 

Nur eine frage.

Wie geht man dann bei der Ersteinrichtung von Unraid richtig vor? (wenn man z.B. über 10TB auf seine Shares schiebt?)

 

1.) Jetzt stell ich schreibcache auf SSDs temporär aus, damit der beim transfer von 10TB logischerweise nicht voll wird.

2.) Pausiere den Parity Sync

3.) Dann stell ich um auf "reconstruct write"

4.) Stell unter den Einstellungen ein das er nur auf eine Disk schreiben soll (bis sie voll ist, damit die auf die anderen keine Lese/schreibzugriffe sind) - Und trotzdem sehe ich dann, wie am Screenshot in meinem Post davor, das es auf den anderen Platten Lesezugriffe gibt?!

 

Beim Transfer der Daten aufs UInraid Share reden wir von größtenteils ISO Dateien von 5-80GB Files.

Und dann hab ich beim Kopieren nach wie vor nur 40mb (eher bisschen weniger)?

 

Kann das echt seine Richtigkeit haben?

Bei TrueNAS hatte ich nen Stripe aus ein paar Disks (Zfs)  und hatte nie Probleme mit dem Kopieren. Da war immer das Gigabit Netzwerk der limitierende faktor.

 

 

 

 

5 hours ago, Laho said:

Leider zu gefreut

Deine Parität ist doch noch gar nicht aufgebaut, wenn ich das richtig sehe. Da ist ein Ausrufezeichen. Dann kann Reconstruct Write denke ich nicht funktionieren. Lass die Parität erstmal erstellen.

1 hour ago, mgutt said:

Deine Parität ist doch noch gar nicht aufgebaut, wenn ich das richtig sehe. Da ist ein Ausrufezeichen. Dann kann Reconstruct Write denke ich nicht funktionieren. Lass die Parität erstmal erstellen.

 

Alles klar. Dann lasse ich mal den Parity Sync mal laufen bis er fertig ist und werde morgen nochmal probieren Daten zu kopieren.

Werde euch berichten. 

 

6 hours ago, Laho said:

Nur eine frage.

Wie geht man dann bei der Ersteinrichtung von Unraid richtig vor? (wenn man z.B. über 10TB auf seine Shares schiebt?)

Entweder viel Geduld oder ohne Parity einrichten und Parity nachträglich erzeugen.

Der zweite Weg sollte aber beinhalten, daß es von den wichtigen Daten immer ein Backup geben sollte.

 

Mit meinen mehr als 300TB kann ich sagen, ohne Parity aufkopieren udn die Parity später erstellen lassen, wenn alles da ist, wo es hin soll, ist defiitiv schneller.

 

6 hours ago, Laho said:

1.) Jetzt stell ich schreibcache auf SSDs temporär aus, damit der beim transfer von 10TB logischerweise nicht voll wird.

Ja, hatte ich auch gemacht, weil ich sonst die TBW der SSD direkt beim Erstzbefüllen signifikant angekratzt hätte.

 

6 hours ago, Laho said:

2.) Pausiere den Parity Sync

Ich würde (bei vorhandenem Backup/Original der Daten) Paritybuild abbrechen,

das Array ohne Parity neu erstellen,

dann Befüllen und

im Anschluß Paritydisk dazu aktivieren und dann Parity erstellen lassen.

 

Wenn Du sicher gehen willst, daß zwischenzeitlich auch nichts schief gegangen ist, nach dem Paritybuild Deine Datenquelle mit Deinen unraiddaten (binär) vergleichen.

Lesend ist das Array ja so normalschnell wie eine einzelne Festplatte.

 

 

6 hours ago, Laho said:

Beim Transfer der Daten aufs UInraid Share reden wir von größtenteils ISO Dateien von 5-80GB Files.

Ja, sowas (Images von Backups) mit sogar einigen hundert GB hatte ich auch dazwischen.

 

6 hours ago, Laho said:

Und dann hab ich beim Kopieren nach wie vor nur 40mb (eher bisschen weniger)?

Das Array in unraid ist wegen der Parität nicht schnell. Deshalb nutzt man ja als Cache eine schnelle SSD, die als Zwischenouffer im normalen Betrieb fungiert und dann in Offzeiten in aller Ruhe auf das Array umkopieren kann. Dafür ist unraid im Array auch eher auf Stromsparen angelegt. Es laufen notwendigerweise eben nicht immer alle Festplatten im Array (an), wenn man ein paar Daten aufkopiert.

 

6 hours ago, Laho said:

Kann das echt seine Richtigkeit haben?

Mit Reconstruct Write sind Geschwindigkeiten fast bis an native Geschwindigkeit einer einzelnen Festplatte möglich. Aber dann laufen eben alle Festplatten in einm Array und unraid frisst soviel Strom, wie man es auch bei einem Raid haben kann.

Ich habe durch "Most free" Regel und ohne Parity (also roundrobin Verteilung der Schreibzugriffe) auf sehr viele leere Festplatten unter zunraid am Anfang sogar viele TB mit mehr als 500MByte/s schreiben können (als ich vor ca. 1,5 Jahren mit unraid anfing).

Aber das ist eben nicht der übliche Praxisfall, sondern war eine Sondersituation, weil eben nie eine Festplatte dauerhaft beschrieben wurde und der riesige RamCahe auch gut mitgeholfen hat.

 

6 hours ago, Laho said:

Bei TrueNAS hatte ich nen Stripe aus ein paar Disks (Zfs)  und hatte nie Probleme mit dem Kopieren.

Dafür liefen dann in dem Array alle Festplatten gleichzeitig und das System fraß dafür mehr Strom, als wenn die Festplatten im Spindown waren.

 

Vielleicht solltest Du nochmal überdenken, was Du wirklich willst und anhand dessen entscheiden, ob unraid das richtige Mittel der Wahl ist.

 

unraid (out of the box/normalbetrieb mit Festplatten im Array): stromsparend und kein RAID, sondern Parity

andere Systeme: Raid, dafür nicht so stromsparend.

7 hours ago, Laho said:

Wie geht man dann bei der Ersteinrichtung von Unraid richtig vor?

 

Es gibt kein "richtig". Entweder mit Ausfallsicherheit (Parity) oder ohne (keine Parity). Entweder mit hohem Stromverbrauch aber schneller (Reconstruct-Write) oder mit niedrigerem Stromverbrauch aber langsamer (read/modify/write).

 

Edited January 26, 20233 yr by hawihoney

13 hours ago, mgutt said:

Deine Parität ist doch noch gar nicht aufgebaut, wenn ich das richtig sehe. Da ist ein Ausrufezeichen. Dann kann Reconstruct Write denke ich nicht funktionieren. Lass die Parität erstmal erstellen.

 

Du und @hawihoney hattet absolut recht.

Zuerst wars die SMR Paritäts Disk die das Problem war (da war damals der Parity Sync schon abgeschlossen und trotzdem brach die Geschwindigkeit ein) und jetzt wars wirklich eben der Parity Sync.

 

Jetzt flutscht es nur so dahin  (so schnell wie es halt mit Gbit Netzwerk geht 😂)

Vielen Dank für eure Unterstützung!

7 hours ago, DataCollector said:

Entweder viel Geduld oder ohne Parity einrichten und Parity nachträglich erzeugen.

 

Ja das hätte Sinn gemacht. Mit dem Wissen was ich jetzt habe, hätte ich es auch so gemacht bevor ich bei allen Shares den Cache deaktiviere.

 

 

 

7 hours ago, DataCollector said:

Ich würde (bei vorhandenem Backup/Original der Daten) Paritybuild abbrechen,

das Array ohne Parity neu erstellen,

dann Befüllen und

im Anschluß Paritydisk dazu aktivieren und dann Parity erstellen lassen.

 

Parity Sync ist über Nacht fertig geworden und ich kopiere eh schon fleißig meine Daten

 

7 hours ago, DataCollector said:

Das Array in unraid ist wegen der Parität nicht schnell. Deshalb nutzt man ja als Cache eine schnelle SSD, die als Zwischenouffer im normalen Betrieb fungiert und dann in Offzeiten in aller Ruhe auf das Array umkopieren kann. Dafür ist unraid im Array auch eher auf Stromsparen angelegt. Es laufen notwendigerweise eben nicht immer alle Festplatten im Array (an), wenn man ein paar Daten aufkopiert.

 

Das habe ich jetzt alles mit Hilfe des Forums nach und nach gelernt und verstanden. 

Als Anfänger ist halt vieles noch unverständlich weil eben bei Unraid einiges anders ist als bei einem klassichen NAS bzw. auch TrueNAS.

 

8 hours ago, DataCollector said:

Dafür liefen dann in dem Array alle Festplatten gleichzeitig und das System fraß dafür mehr Strom, als wenn die Festplatten im Spindown waren.

 

Vielleicht solltest Du nochmal überdenken, was Du wirklich willst und anhand dessen entscheiden, ob unraid das richtige Mittel der Wahl ist.

 

unraid (out of the box/normalbetrieb mit Festplatten im Array): stromsparend und kein RAID, sondern Parity

andere Systeme: Raid, dafür nicht so stromsparend.

 

Doch, doch Unraid ist für mich die richtige Wahl. Und auch wenig Stromverbrauch ist natürlich in der heutigen Zeit ein Thema.

Sobald mal meine Daten alle auf den Unraid Shares liegen werde ich den Recunstruct Write wieder deaktivieren und den Cache zumindest für Share aktivieren von denen oft gelesen wird (z.B. Filme, worauf plex später zugreifen wird).

 

Jedenfalls auch ein großes Danke an dich, das du dir Zeit genommen und das so aufschlussreich erklärt hast. 

Ist ne super Community hier.

 

17 hours ago, Laho said:

Cache zumindest für Share aktivieren von denen oft gelesen wird

Falsche Annahme. Der Unraid Cache ist ein Schreibcache für neue Daten, kein klassischer Lesecache. Einfach mal die Hilfe auf der Detail-Seite eines Shares aktivieren (achte zusätzlich auf das kleine Wörtchen new). Den Lesecache übernimmt Unraids Linux Unterbau. Und das eigentlich sehr gut.

 

Quote

Specify whether new files and directories written on the share can be written onto the Cache disk/pool if present. This setting also affects mover behavior.

 

Edited January 27, 20233 yr by hawihoney

Bevor ich einen neuen Beitrag aufmache, häng ich mich hier mal mit ein. Ich befülle gerade meinen Server mit Fotos und Videos. Ist diese Performance ok oder kann ich noch was tun?

 

 

Ich habe einen Share, den ich per NFS von meiner Linux Maschine mit rsync befülle. Angebunden per 10 GBE per DAC. Der Share hat als allocation method fill up. Turbo write habe ich ausgeschaltet da es keinen Unterschied gab. Den Parity sync habe ich ausgeschaltet. Aufs Caching verzichte ich gerade. Könnte ich aber umstellen auf 1TB NVME.

 

Könnte es noch schneller gehen? Warum liest die Parity und Disk 2? 

 

Vielleicht habt ihr noch ein paar Tips für blutige Anfänger.

 

Danke und Grüße

RWEK

12 minutes ago, RWEK said:

Turbo write habe ich ausgeschaltet da es keinen Unterschied gab.

dann hast du entweder in dem Moment Unmengen an kleinen Dateien nur kopiert oder dein Netzwerk wäre am Limit (unwahrscheinlich).

 

mit Turbo (reconstruct) ist normal die beschreibende HDD (oder Parity) das Limit ... was wesentlich höher sein sollte ...

 

16 minutes ago, RWEK said:

Aufs Caching verzichte ich gerade.

zum Befüllen würde ich auch immer direkt auf Array schreiben, aber da hängt es ja aktuell ... Ausnahme, viele viele kleine Dateien ... da macht der Cache (ssd) schon Sinn.

21 minutes ago, RWEK said:

Bevor ich einen neuen Beitrag aufmache, häng ich mich hier mal mit ein.

 

ungünstig. Bitte bei neuen Problemen/Situationen etc.. neuen Beitrag machen.

 

 

21 minutes ago, RWEK said:

Ich befülle gerade meinen Server mit Fotos und Videos. Ist diese Performance ok

 

Du hast ein Festplattenarray mit Parity, mehr als 2 Datenträgern und eine Schreibrate von über 70MByte/s. Das ist okay.

 

21 minutes ago, RWEK said:

oder kann ich noch was tun?

 

Grundlagen unraid - (Bitte Dokumentation lesen):

Wenn man schneller schreiben will:

 Pool mit SSD vorschalten.

 Solange dann auf die SSD geschrieben werden kann ist es so flott, wie diese SSD eben kann.

 Wenn die SSD/Pool zu weit gefüllt wird, wird dann auf das Array duerchgeschrieben und es ist wieder langsamer. Deswegen sollte SSD ausreichend groß sein, für den Zwischenzeitraum, in dem der Mover nicht läuft.

 

Bei Erstbefüllung wird empfohlen ohne Parity zu arbeiten, weil man dann die native Geschwindigkeit der Festplatten erreicht.

 

Ein Array mit mehr als 2 Datenträgern und Parity wird durch Parity schreibend immer auf 33-50% der nativen Festplattengeschwindigkeit gebremst.

Deshalb ja die Empfehlung einen Pool mit SSD(s) vorzuschalten und den Mover dementsprechend einzuschalten und nutzen.

 

21 minutes ago, RWEK said:

Ich habe einen Share, den ich per NFS von meiner Linux Maschine mit rsync befülle. Angebunden per 10 GBE per DAC.

 

....was alles die Festplatten auch nicht beschleunigt. Auf gute SSD hingegen sollten ca. 1GByte/s möglich sein.

 

 

21 minutes ago, RWEK said:

Aufs Caching verzichte ich gerade.

 

...was die Schreibrate ins Share auf Arraygeschwindigkeit bremst

 

21 minutes ago, RWEK said:

Könnte ich aber umstellen auf 1TB NVME.

 

....was die Schreibrate ins Share für ca. 1TB Volumen beschleunigt, danach wird wieder direkt ins Array geschrieben.

 

21 minutes ago, RWEK said:

Könnte es noch schneller gehen? Warum liest die Parity und Disk 2? 

 

Weil es die Paritydaten lesen muß um sie zu kennen und dann korrekt anzupasen und neu zu schreiben.

Das bremst eben. unraid Grundlagen.

 

21 minutes ago, RWEK said:

Vielleicht habt ihr noch ein paar Tips für blutige Anfänger.

 

Entweder nutzt Du bei der Erstbefüllung das Array ohne Parity oder schaltest den SSD Pool davor um zumindest für dessen Kapazität mehr Geschwindigkeit zu haben (was er mover aber dann später ebensolangsam ins Array schreiben muß).

 

Edited November 13, 20241 yr by DataCollector

Super. Danke für die ausführlichen Antworten! Du bist wie immer auf Zack!

 

Jetzt habe ich verstanden. Würde der Mover auch automatisch anspringen wenn ich vor meinem Ausführungsplan bin aber der Cache voll ist?

38 minutes ago, RWEK said:

Würde der Mover auch automatisch anspringen wenn ich vor meinem Ausführungsplan bin aber der Cache voll ist?

Nein, nur Timer gesteuert

1 hour ago, RWEK said:

Super. Danke für die ausführlichen Antworten! Du bist wie immer auf Zack!

 

Wie ich beim Absenden gesehen habe, war alturismo einige Sekunden schneller. 😄

 

1 hour ago, RWEK said:

Jetzt habe ich verstanden. Würde der Mover auch automatisch anspringen wenn ich vor meinem Ausführungsplan bin aber der Cache voll ist?

 

 

per Default: nein. Aber man kann ihn manuell anstoßen.

Es gibt auch ein plugin um den Mover feiner anzupassen, aber nach ersten Versuchen (und der Feststellung, dass ich da wohl etwas verstellt hatte) habe ich das Plugin wieder entfernt.