hawihoney

Ich hatte nur dem Thread-Ersteller geantwortet. So unter uns: Ich hatte auch anfangs über MD5 Verfahren nachgedacht. Als alter Entwickler hätte ich das aber selbst gebaut. Später habe ich mich dagegen entschieden. Bisher - ToiToiToi - nach 15 Jahren, 3 Servern, knapp 80 Festplatten, ist noch nicht eine Differenz beim Sync aufgetreten, die sich nicht durch Stromausfall oder defekte Kabel erklären ließen. Mittlerweile bin ich, was das Thema angeht, völlig entspannt.

Doch. Das Verfahren ist im Unraid Manual beschrieben. Uneven Parity Calc. Ist bei allen RAID Systemen mehr oder weniger das selbe zugrunde liegende Verfahren. Weder Unraid noch Dein System sind da Besonders. Ich wette das die Datenplatte in Ordnung ist und die Parity korrigiert werden muss. Hat was mit der Reihenfolge der Abläufe zu tun. Auch diese vier Schritte sind im Manual beschrieben. Such mal nach dem Performance Abschnitt. Moderne Dateisysteme haben Transaktions-Logs und arbeiten die beim Reboot ab. Dadurch kann es beim Crash zu Unterschieden kommen. Muss halt nur gesynct werden. Die Frage ist nur: Wieso der Crash. Passierte hier 2x in 15 Jahren. Einmal wars der Elektriker vom Markisenbauer, einmal ein nasser Stecker an der Brunnenpumpe ...

Waren das Sync Fehler? Wenn Du mehr als eine Datenplatte hast, dann musst Du das Standardverfahren anwenden - Parity korrigieren. Sonst werden Fehler bei einem Ausfall einer weiteren Datenplatte auf dieser weiteren Platte erzeugt. Parity muss passen sonst erzeugt man weitere Fehler. Datenplatten haben immer Recht, selbst wenn auf Ihnen Müll liegt... Es wird immer Richtung Parity gesynct. Nur bei einem Rebuild geht es in die andere Richtung. Da hilft auch kein Backup wenn mitten im Schreiben neuer Daten der Stecker gezogen wird. Also: Bei Sync Fehlern - Parity Prüfung durchlaufen lassen. Bei Schreib-/Lesefehlern wieder melden.

Darf ich noch etwas hinzufügen? Wenn es etwas umfangreichere Skripte mit zusätzlichen eigenen Modulen werden dann kannst Du natürlich auch Folgendes machen: #!/usr/bin/bash #arrayStarted=true #backgroundOnly=true #clearLog=true #noParity=true python3 /mnt/disk1/Projekte/Projekt1/Source/BlaBla.py Vorteil: Auch für komplexe Skripte geeignet. Programmierung nicht auf Flash. Nachteil: Die Platte fährt ggfs. hoch.

Muss nicht extra installiert werden. In der GUI des User Scripts Plugin einfach "Custom" Schedule und dann daneben "15 17 * * *" eingeben. Dann hat man alles an einer Stelle.

Wieso arbeitest Du mit der script Datei? Das kann man doch über die GUI des Plugins viel komfortabler - inkl. Cron Schedule. Und ja: "docker start <containername>" - mehr braucht es nicht.

User Scripts Plugin. Zum Starten: docker start <containername> Zum Stoppen; docker stop <containername> Startzeit als Custom Schedule:

In Deinen Ausführungen sind diverse Unschärfen/Fehler enthalten. 1. Das ist so nicht korrekt. Unraids FS Unterstützung kommt von ReiserFS über XFS zu BTRFS und nun ZFS. Die Unterstützung von ReiserFS läuft aus. Im Array werden einzelne Platten mit XFS, BTRFS und ZFS unterstützt. Die Erfahrungen sind unterschiedlich. Ich habe vor einigen Jahren alle Arrays von ReiserFS zu XFS migriert und werde auch so schnell nicht mehr wechseln da rock-solid. BTRFS kommt mir aus verschiedenen Gründen nicht ins Haus und ZFS werde ich für zukünftige Pools im Auge behalten. Also nein, Unraid ist nicht standardmäßig auf ein einzelnes FS ausgelegt. Quote aus dem Unraid Manual. Siehe hier: https://docs.unraid.net/unraid-os/getting-started/quick-install-guide/#starting-the-array-and-formatting-your-devices 2. ZFS wird spätestens seit 6.12.x standardmäßig unterstützt. Es gibt noch einige Arbeiten in der Oberfläche um die Unterstützung rund zu machen. Diese werden für das nächste Release erwartet. Aber ZFS wird auf jeden Fall bereits jetzt standardmäßig im Array (Single Disk) und in Pools unterstützt. 3. Ich verstehe diese Aussage nicht. Welche Anpassungen? Welche Kompatibilitätsprüfungen? 4. ZFS läuft out-of-the-box spätestens seit 6.12.x unter Unraid. Weitere Tools sind nur für Randgebiete erforderlich. Man muss für die Unterstützung einer GPU keine zusätzlichen Plugins installieren - kann man aber. So ist es auch bei ZFS. Man muss keine zusätzlichen Tools installieren - kann man aber.

I know. I tried sabnzbd in 2023/Q1 but came back to NZBGet. Ressource (e.g. CPU) usage of sabnzbd was way above NZBGet. And the GUI - whow, what a difference between the clear interface of NZBGet compared to sabnzbd. sabnzbd looks to me like a prototyp v0.1. Just my personal opinion. Will try. Thanks for pointing this out.

@ich777 I do have problems with German Umlauts in the NZBGet Container. Filenames containing äöü, etc. are cut off in front of these characters. Sometimes these files become deleted - don't know why. In the NZBGet forum I found old threads about UTF-8 vs. UTF-16 and the NZBGet creator hugbug wrote that NZBGet has no problems. So my idea is, perhaps the "old" (5.7) unrar in this container has a problem. I'm using NZBGet since many, many years and I don't remember that I always had any problems with these characters in the past. Is it possible to update unrar in the NZBGet container? It would be a first step to eliminate any problems with unrar. If this doesn't help I need to dig into the preprocessing scripts of NZBGet. It's a long time ago that I wrote those ... Thanks in advance. P.S: If you are interested I can PM you a NZB file to show my problem.

Interessant. Hast Du eine Ahnung wohin sich das Teil installiert? So ohne /config/ und .../appdata/? Vielen Dank.

Is there a reason why numbers show different scalings depending on it's value? IMHO it's hard to follow with old eyes: My feature request: Use the same scaling on all numbers within GUI - including Dynamix File Manager. Alternatively make it an option in Display settings. Thanks for listening.

Ich habe ein dutzend MG08ACA16TE in der 18 TB Ausführung verbaut. Die unterscheiden sich von den restlichen Platten im System in keiner Weise. Im Array sind die genauso schnell oder langsam wie alle anderen.

Wenn es sich nur um den gemappten "data" Pfad handelt, dann hätte ich nur den Nextcloud Container gestoppt, den Inhalt des "data" Pfades auf die neue Platte kopiert (vorsichtshalber), den Host-Path für das "data" Mapping in den Container Einstellungen angepasst und anschließend den Container neu gestartet. Mehr hätte ich zunächst nicht gemacht. Und wenn dann alles ein paar Tage läuft, dann die Original "data" Quelle löschen. Und Backup von Nextcloud nicht vergessen anzupassen - sofern Du ein solches machst. Und wenn man Paranoid ist, ein Backup von der zugrundeliegenden Datenbank machen (mariaDB). Genau das ist das charmante am Docker System. Das Umziehen von Containern oder Pfaden ist total einfach. Warum in den Maintenance Mode gehen? Hast Du einen Grund dazu? Ich habe jahrelang jede Nacht den Nextcloud Container gestoppt, eine Sicherung gezogen und den Container wieder neu gestartet. Den Maintenance habe ich in den ganzen Jahren nur einmal benötigt - da war ein Update hängen geblieben.

Unsere PV von 2019 alleine ist nach 6 Jahren bezahlt. Aktueller Zwischenstand mit tagesaktueller Strompreisberücksichtigung (Stand gestern): Und was die Ressourcen angeht: PV zu ca. 90-95 % recyclebar, Batteriespeicher ca. 95% der Metalle, 50% des Lithiums. In 20 Jahren wird das wohl besser sein. Das ganze entwickelt sich gerade erst. Ich bin da sehr zuversichtlich. Das Öl, das Gas hingegen, ist zu 100 % weg. 0 % recyclebar. P.S.: Sehe gerade die Rundungsdifferenz im SQL-View. Lustig ...

Das kommt darauf an Gestern 26.10. war unser Batteriespeicher exakt ein Jahr alt und ich kann für unsere Investition/Verbrauch/Nutzung/Strompreis etc. genaue Auskünfte geben. PV und Speicher sind nach einem schwachen Sonnenjahr, aber hohen Strompreisen, nach etwas um die 9 Jahren amortisiert. Dabei hat aber die PV einen höheren Anteil als der Batteriespeicher. Unser Speicher-Hersteller garantiert nach Ablauf der Garantie (10 Jahre) noch 80 % Kapazität. Soll angeblich 20 Jahre halten. Die PV von Bekannten hält seit 25 Jahren. Ich gehe davon aus, dass sich auch der Batteriespeicher mehr als rentiert. Allerdings "rechnen" wir auch eine emotionale Komponente mit ein. Wir wollen auch etwas für Klima, Umwelt, etc. tun ... Und unter diesem Aspekt "lohnt" sich das alle Male. Für den, dem die Welt der Kinder, Enkel egal ist, für den mag es sich nicht lohnen ,,, Letztens in der Nachbarschaft (3 Kinder, 2 Enkel): Das sieht doch sch...e aus auf dem Dach. Das sieht doch jeder. Nur über meine Leiche bekommen wir PV aufs Dach.

Auf jeden Fall das komplette syslog. Üblicherweise lädt man bei Problemen die komplette, anonymisierte ZIP Datei mit in den Beitrag. Wer sich mit dem jeweiligen Problem beschäftigen möchte fischt sich dann das Passende raus.

Kurze Nebenbemerkung. Für eigene/custom Mounts wurde vor Kurzem /mnt/addons/ eingeführt: https://forums.unraid.net/topic/92462-unassigned-devices-managing-disk-drives-and-remote-shares-outside-of-the-unraid-array/?do=findComment&comment=1235803

Hatte ich ja geschrieben und den OP gebeten mal auf top zu gucken. Lustig finde ich aber die Aufteilung der Last. Die 6 Performance Cores (durch IO-wait?) am Anschlag und die 8 Effizienz Cores schlafen ... https://www.intel.de/content/www/de/de/products/sku/230493/intel-core-i513600k-processor-24m-cache-up-to-5-10-ghz/specifications.html

Mich stört die CPU Auslastung. Öffne vor dem nächsten Kopieren mal die Konsole und starte top. Guck mal ob das System nicht einfach nur wartet - sprich IO-wait. Das findest Du dann oben als "wa" Wert. 30 MB/s ist tatsächlich, selbst für das Unraid Array, über 50 % zu wenig. Das muss Hardware Gründe haben. Die vielen Vorteile des Arrays kommen halt mit dem Nachteil beim Schreiben. Nimm die Performance der langsamsten Platte und teile das durch ungefähr 3,5. Hier die Erläuterung: https://docs.unraid.net/unraid-os/manual/storage-management/#array-write-modes

In Kürze, da bedarf es m.M.n. keiner Übersetzung:

Wenn Plex hw anzeigt, dann wird die iGPU genutzt. Da gibt es nichts zu diskutieren. Kannst ja mal in die Plex Logs schauen was es erkannt hat. Warum ein Plugin etwas nicht anzeigt müsste man dort fragen.

Hast Du eine iGPU oder eine dGPU oder beides? Wenn nur iGPU dann ist Deine Aussage falsch. Mit hw bedeutet dann iGPU, ohne hw bedeutet Software AKA CPU.

Bist Du evtl. hiervon betroffen (Fritzbox?)? Wenn ja, hast Du diese Änderungen vorgenommen: https://docs.unraid.net/unraid-os/release-notes/6.12.4/#fix-for-macvlan-call-traces

Das ist eindeutig. Die Datenbank ist kaputt. Hast Du Backups? Hast Du automatische Backups in den Plex Einstellungen "Geplante Aufgaben" eingerichtet? Die gelben Warnungen sind irrelevant, Plex hat immer einen Mismatch zwischen den Feldern in der Datenbank und seinen Abfragen. Das ist schon lange so.