Hallo Leute,

Habe eine eher ungewöhnliche Frage, ist es möglich das innerhalb des Arrays z.b: Disc1 nicht auf die Parity Platte schreibt?

Gibt es vielleicht ein Script dazu.

Frage deswegen da die Displaysoftware unbedingt auf Disc1 liegen muss aber diese dann die Parityplatte nicht in Schlafmodus lässt.

Oder könnte ein Profi unter euch einen Docker Container für Unraid erstellen für das Display. ;-)

Ich kenn mich für soetwas zu wenig aus.

Vielen Dank

Edited January 30Jan 30 by Zerosthunder

6 hours ago, Zerosthunder said:

ist es möglich das innerhalb des Arrays z.b: Disc1 nicht auf die Parity Platte schreibt?

Gibt es vielleicht ein Script dazu.

Nein, Parity ist block based.

6 hours ago, Zerosthunder said:

Frage deswegen da die Displaysoftware unbedingt auf Disc1 liegen muss aber diese dann die Parityplatte nicht in Schlafmodus lässt.

ich schätze da interpretierst du etwas falsch, es geht darum das es persistent ist.

teste mal /mnt/cache/... oder was auch immer du als pool name nutzt und pass die Pfade jeweils an, würde mich schwer wundern wenn nicht ...

8 hours ago, Zerosthunder said:

Frage deswegen da die Displaysoftware unbedingt auf Disc1 liegen muss aber diese dann die Parityplatte nicht in Schlafmodus lässt.

Was bitte ist denn die "Displaysoftware" ???

Ansonsten, wenn irgendwo auf Array geschrieben wird, MUSS immer die Parity Platte nachgeführt werden, sonst wäre sie ja sofort ungültig.

Also, wenn diese ominöse "Displaysoftware" unbedingt dauernd was schreiben will, sollte man schauen, ob die Daten so wichtig sind, dass sie ins Array gehören, wenn nicht, dann den Kram in einen eigenen Pool auslagern.

Also, bei dem im Video angegebenen Skript als Pfad nicht "/mnt/disk1" angeben, sondern z.B. /mnt/cache (oder einen anderen Pool, Du hast ja 4 NVMe Slots zur Verfügung, also pack was rein)

Edited January 31Jan 31 by MAM59

Hallo

Danke für die Antworten, jup jetzt funktioniert es im Cache, danke euch.

Habe es gestern einigemal versucht und es wollte einfach nicht, heute ging es auf anhieb :-))

Danke trotzdem nochmal.

On 1/31/2026 at 10:53 AM, Zerosthunder said:

Hallo

Danke für die Antworten, jup jetzt funktioniert es im Cache, danke euch.

Habe es gestern einigemal versucht und es wollte einfach nicht, heute ging es auf anhieb :-))

Danke trotzdem nochmal.

Kannst du mir sagen wie genau du es nun gemacht hast? Bin auch demnächst besitzer eines solchen NAS und würde ebenfalls gerne das Display nutzen. Danke. Hast du sonst noch nützliche Tipps und Tricks für mich?

Schon etwas her, aber ...

Auf YT gibt es im AOOSTAR-Kanal ein Tutorial für die Nutzung des Displays als Hardwaremonitor unter UNRAID.
Darin wird, wie der TE anmerkt, jedoch initial die Software auf Disk1 abgelegt und das Script arbeitet auch mit diesem Pfad.
Daher seine Bedenken, dass für diesen Fall die Platte wohl nicht angehalten wird, wenn das Script läuft (zumal auch ein Log geschrieben wird).

Habs soeben mal laut Tutorial eingerichtet (bin ein absoluter LinuxNoob) und werde berichten was geändert werden muss.
Laufen tut es wie vorgesehen. Die Konfiguration erfolgt übrigens per Webinterface.

Download der Resource hier: https://mega.nz/folder/Ey0EyZCS#PsugvEt4qF3II_wDOm-_vQ

Edit:
Habe ein Share eingerichtet und auf das SSD-Cachelaufwerk beschränkt.
Der ursprüngliche Ordner auf disk1 ist nun leer.
Pfad im Skript wurde natürlich angepasst.

Mal sehen ob das so klappt, sobald das NAS vollständig bestückt ist, beladen wurde und auch die Parityerstellung durch ist.
Wird wohl etwa 10 Tage dauern.
Beladen werde ich nach Möglichkeit initial per USB3 und künftig über ein 2.5 G-LAN (ist auf dem Weg).

Vorgesehener Ausbau des Datengrabes vorerst mit 2 x 16 TB Exos und 3 x 4 TB WD red (alte Platten) für das Array, 1 x 16 TB Exos als Parität, 1 TB SSD als Cache, gebootet wird intern von einer kleinen SSD (mit 512GB zu klein für W11 daher übrig).

Unglücklich bin ich aktuell noch mit der grottigen Performance des Movers!

Dieser schafft beim Kopieren nur 60 MByte/s und lastet dabei nur einen Kern maximal aus (die Tips, das zu beschleunigen, habe ich bereits durch).
Wenn ich also derzeit über 1 G-LAN mit vollem Speed belade, ist der Cache immer irgendwann voll.
Eventuell wechsle ich da zur Abmilderung noch zu einer 4TB-SSD.
Möglichwerweise wird das NAS intern auch etwas schneller, wenn Grundkonfiguration und Parity erledigt sind.

Edited July 13Jul 13 by HuDiNi
Ergänzung und mögliche Lösung

On 5/30/2026 at 1:23 PM, danschde said:

Kannst du mir sagen wie genau du es nun gemacht hast? Bin auch demnächst besitzer eines solchen NAS und würde ebenfalls gerne das Display nutzen. Danke. Hast du sonst noch nützliche Tipps und Tricks für mich?

Siehe oben

19 hours ago, HuDiNi said:

Wenn ich also derzeit über 1 G-LAN mit vollem Speed belade, ist der Cache immer irgendwann voll.
Eventuell wechsle ich da zur Abmilderung noch zu einer 4TB-SSD.

zum initialen Befüllen solltest du den Schreibcache deaktivieren (das Ziel-Share so einstellen, das primary storage direkt aufs array zeigt), denn wenn Du z.B. 20TB auf Dein Array kopieren willst, reicht dein schneller(er) Cache nie aus, egal ob er 1 oder 4TB groß ist.

Nach dem Befüllen macht der Cache dann Sinn, damit maximal schnell kopiert werden kann und das Array dabei im SpinDown bleibt und erst der Mover die Daten ins Array schiebt, eben weil Du dann eher weniger pro Tag auf den Server schiebst. Wie viel das sein wird, kannst nur Du wissen und führt dann eben zur idealen Cachegröße...

19 hours ago, HuDiNi said:

Möglichwerweise wird das NAS intern auch etwas schneller, wenn Grundkonfiguration und Parity erledigt sind.

die Konfiguration wird keine Performance ziehen, das Lesen/Schreiben der Parity natürlich schon. Mein 18TB Parity-Check dauert ca. 19-23h mit >200MB/s:

vielleicht solltest Du das Aufbauen der Parity erstmal durchlaufen lassen, bevor Du das System befüllst...

On 7/14/2026 at 8:07 AM, _alo_ said:

zum initialen Befüllen solltest du den Schreibcache deaktivieren (das Ziel-Share so einstellen, das primary storage direkt aufs array zeigt), denn wenn Du z.B. 20TB auf Dein Array kopieren willst, reicht dein schneller(er) Cache nie aus, egal ob er 1 oder 4TB groß ist.

Danke, werde ich mal so testen.

Vermutlich werde ich später gar keinen SSD-Cache nutzen (müssen).

Ich kann ja über 2.5G ohnehin nur mit fast der Schreibgeschwindigkeit der Exos X24-Platten im Array schreiben (rund 280 MByte/s). Und auf das kleine bischen mehr oder weniger kommts dann auch nicht mehr an.

Das Befüllen einer Platte mit 16 TB dauert so oder so etwa einen vollen Tag.
Real dauert das Schaufeln vom Inhalt einer der externen 4TB-Platten 6-8 Stunden, egal ob übers Netz oder direkt am USB vom NAS.

Die Exos-Platten haben initial beim Löschen, nach dem Zufügen ins Array, knapp über 290 MByte/s und die letzte Platte ist aktuell (70% fertig genullt, 5-6h vor Abschluss laut Statusanzeige) bei nur noch 210 MByte/s angelangt.

PS:

10G über SFP + wäre noch eine Option, macht aber ohne SSDs dann nur wenig Sinn, ... 🤔

Mal sehen, ob mir noch ein Nutzen für die bis zu 4 M.2 (im Aoostar 2 x mit x2 und 2 x nur per x1 angebunden) einfällt.
Im Haupt-PC sind 4 Stück NQ790 bei ähnlicher Anbindung auch höchstens rund 800 MByte/s schnell.

Edited July 25Jul 25 by HuDiNi

4 minutes ago, HuDiNi said:

10G über SFP + wäre dann noch eine Option, macht aber ohne SSDs dann nur wenig Sinn, ... 🤔

Würde auch MIT SSD wenig Sinn machen, denn irgendwann ("schneller als Du denkst") ist die SSD voll und dann passiert DAS GRAUEN!

Also diese Massenaktionen besser OHNE Cache durchführen, das erscheint zwar langsam, aber ist im Endeffekt schneller, denn wenn die SSD voll ist, blockiert die Kiste komplett und je nach Mover Einstellungen dauert es Stunden, bis wieder einigermassen Fahrt aufgenommen werden kann.

Glaub mit, das willst Du gar nicht miterleben...

Ach ja, mach Dir keine Hoffnung auf >200Mb/s oder so. Ein UNRAID Array kommt selten über 60 MB/s. Das Schreiben der Parity zieht die Kiste echt runter.

Ein Trick für die Massenbefüllung:

• Parity abschalten

• Daten kopieren (ohne Cache)

• Parity wieder einschalten/neu erstellen lassen

Geht im Endeffekt meist deutlich schneller, als bei jedem Block die Parity nachführen zu lassen.

Edited July 25Jul 25 by MAM59

4 minutes ago, MAM59 said:

Glaub mir, das willst Du gar nicht miterleben...

Hab ich schon, ... 😁

Der Mover belegt nur EINEN Kern zu 100%.
Und auch wenn hier im Forum anderes verlautet wird, bin ich mir sicher, dass der Prozess einer Optimierung bedarf (mehrere Kerne nutzen oder "was weiß ich schon" 🫣), ...

Die maximale Schreibgeschwindigkeit der Platten (bei zugleich deaktiviertem Parity) wird durch den Mover nicht mal annähernd erreicht (nach wenigen Minuten UNTER 100 MByte/s).

Weiteres Nachschieben von Daten auf zB das halbleere Cachedrive verschlimmert das Ganze weiter. Der tatsächliche Nutzen dieser Möglichkeit entzieht sich mir aktuell völlig. ☹️

Edited July 25Jul 25 by HuDiNi

23 minutes ago, MAM59 said:

Parity abschalten

18 minutes ago, HuDiNi said:

Hab ich schon, ... 😁

Alternative wäre gewesen, Turbo write ON zumindest zum Befüllen

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/overview/#turbo-write-reconstruct-write

dann hat man normal native Geschwindigkeit da nicht r/w/m parallel laufen muss, es laufen halt alle Platten dann, das sollte in Summe die schnellste Variante sein.

19 minutes ago, HuDiNi said:

Der Mover belegt nur EINEN Kern zu 100%.

ich schätze eher das ist disk i/o und nicht echt CPU Last, da wartet halt alles bis es weiter geht ...

9 minutes ago, alturismo said:

ich schätze eher das ist disk i/o und nicht echt CPU Last, da wartet halt alles bis es weiter geht ...

Muss man erklären:

• Unraid zeigt bei CPU Last die IO Queue mit an, man kann also nicht sehen/sagen ob wirklich ein Kern ausgelastet ist, oder ob eine Plattenqueue voll ist und den Kopiertask suspendiert hat.

• Bei Massenkopieren ist es aber meistens die blockierende Platte

(den Benefit von Turbowrite konnte ich in der Praxis noch nicht belegen. Der Unterschied ist nur "lahm" zu "ganz lahm". Es dauert auf jeden Fall Stunden und wenn man davor hockt, und wie ein Kaninchen auf die Schlange starrt, wird einem so oder so langweilig. Also: anwerfen und was anderes machen)

Edited July 25Jul 25 by MAM59

3 minutes ago, alturismo said:

Alternative wäre gewesen, Turbo write ON zumindest zum Befüllen

Ist natürlich bereits AN, nachdem ich nach ersten (unbefriedigenden) Tests auf die Suche nach Lösungen für das geschilderte Problem gegangen bin. 😇

4 minutes ago, alturismo said:

ich schätze eher das ist disk i/o und nicht echt CPU Last, da wartet halt alles bis es weiter geht ...

Mag sein (spielt am Ende keine Rolle wo was zu optimieren wäre), am Ende hab ich nur OHNE Cache die volle Schreibgeschwindigkeit der Platten, mit Cache nur wenige Minuten einen Benefit.
Siehe oben: Worin liegt der eigentliche Nutzen eines (vermeindlich schnellen) Cache-Laufwerks im täglichen Betrieb? Ich sehe schlicht (aktuell) keinen.

Ich verstehe von der Materie vermutlich zu wenig, bin aber lernwillig, ...

Ich schaufle übrigens Datengrößen von wenigen MByte (MP3 oder anderes Audioformat, davon Hunderte am Stück) bis nahe 100 GByte (Blueray-Image, Videos meiner ActionCam).

Edited July 25Jul 25 by HuDiNi

Sorry übrigens an den TE fürs Entführen des Threads, ... 😊

3 minutes ago, HuDiNi said:

Siehe oben: Worin liegt der eigentliche Nutzen eines (vermeindlich schnellen) Cache-Laufwerks im täglichen Betrieb? Ich sehe schlicht (aktuell) keinen.

doch, den gibt es schon.

Wenn Du im "normalbetrieb" mal hier und da eine grosse Datei rüberschiebst (Backups / Videos usw) "schnupft" der Cache die dann locker weg (bei mir mit 10G LAN)

Später kommt dann der Mover und schaufelt sie in aller Ruhe um auf das lahme Array.

Der Cache fängt also die Peaks ab und schont Deine Nerven. Mich interessiert es schon, ob ich 3min auf einen Film warten muß oder ob die Sache in 30s gegessen ist (neue Filme werden immer vor dem Frühstück aufbereitet, gescraped und dann ins Array kopiert)

Muss nur groß genug sein für die Laufdaten des Tages. Also ich komm locker mit 512Gb aus (weil ein Backup meines Arbeitsplatzes schon so an die 300Gb ranreicht)

Aber, wenn die zu transferierende Datenmenge zu groß ist, wie bei einer Erstbetankung, dann ist der Cache kontraproduktiv.

Edited July 25Jul 25 by MAM59

2 minutes ago, MAM59 said:

bei mir mit 10G LAN

Das wird der Knackpunkt sein. Hab eh schon oben geschrieben, dass ich per SFP+ diese Option auch noch hätte.
Ich nutze ja derzeit 2.5G LAN.

Was die Begründung dafür ist, dass der Mover intern (bei deaktiviertem Parity) mit nichtmal annähernd 100 MByte/s nicht die volle Schreib-/Leserate der Platten nutzen kann, weißt du nicht zufällig?
Da ich mit vollem Netzwerkspeed die HDD-Platten und auch den Cache selbst befüllen kann, empfinde ich das als mehr als nur merkwürdig.

Vom Windows PC kenne ich ein solches Verhalten nicht (da ist es höchstens vom internen SSD-Cache abhängig, je nach Dateigröße).

Edited July 25Jul 25 by HuDiNi

1 minute ago, HuDiNi said:

Was die Begründung dafür ist, dass der Mover intern (bei deaktiviertem Parity) mit nichtmal annähernd 100 MByte/s nicht die volle Schreib-/Leserate der Platten nutzen kann, weißt du nicht zufällig?

Das ist Absicht. Er soll ja als stummer Diener im Hintergrund den Dreck wegräumen.

Da kommt es nicht auf Speed an, sondern auf Unauffälligkeit.

Du sollst auf keinen Fall von seiner Arbeit behindert werden, deshalb zieht er sofort die Füsse ein, wenn sich im System etwas rührt. Ist also mehr am Schlafen, als am Kopieren.

Ein Hauptgrund ist neben Bequemlichkeit und abfangen der Peaks eben auch der Stromverbrauch. Wenn für jede Mini Datei immer zwei hdds (Daten+parity) anspringen und für 15min (default spindown) laufen und dabei ja 5W ziehen kann das über den Tag schon viel werden. Der Verbrauch der ssd ist dagegen kaum messbar.

Mein Backup Server läuft ohne parity. Wenn das skript läuft zeigt rsync nahezu volle Bandbreite an (meist über 200MB/s bei 2,5Gb LAN mit Flow Control), k.a. Warum das bei dir so langsam ist.

17 minutes ago, _alo_ said:

Ein Hauptgrund ist neben Bequemlichkeit und abfangen der Peaks eben auch der Stromverbrauch.

Das Optimieren hiervon wird die nächste Baustelle.

Ich bin ab morgen 10 Tage mit dem Motorrad unterwegs und lasse das mal mit dem Shellyplug laufen (kann dann auch mal ein paar Tage Parity fertig schreiben).
Fritz-VPN und Jellyfin für Tests hab ich bereits eingerichtet.
Ich mach denn neue Threats auf, falls es noch was zu klären gibt.

Danke mal bis hierhin.

1 hour ago, MAM59 said:

(den Benefit von Turbowrite konnte ich in der Praxis noch nicht belegen. Der Unterschied ist nur "lahm" zu "ganz lahm". Es dauert auf jeden Fall Stunden und wenn man davor hockt, und wie ein Kaninchen auf die Schlange starrt, wird einem so oder so langweilig. Also: anwerfen und was anderes machen)

hier war es immer von ~ 70 - 80 MB/s auf > 200+ MB/s wie es auch sein sollte.

habe ich eine SMR Platte dabei (gerade als Parity) dann hilft es wahrscheinlich weniger.

1 hour ago, HuDiNi said:

Ist natürlich bereits AN, nachdem ich nach ersten (unbefriedigenden) Tests auf die Suche nach Lösungen für das geschilderte Problem gegangen bin. 😇

wundert mich, aber ok, wird wohl in deiner Konstellation so sein.

Ich kann es nicht mehr lokal quer testet da ich lokal keine Parity mehr nutze, bin komplett auf Spiegelserver umgestiegen für den Fall eines Ausfalls, aber mal schauen, zumindest einer der von mir "gewarteten" Server hat noch Parity.