HuDiNi

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.

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).

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

Ist natürlich bereits AN, nachdem ich nach ersten (unbefriedigenden) Tests auf die Suche nach Lösungen für das geschilderte Problem gegangen bin. 😇 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).

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. ☹️

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.

Siehe oben

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.