mgutt

Wird es bei den zwei 4TB HDDs bleiben. Oder gar Wechsel auf SSD only finanziell denkbar?

unRAID hat eine gewisse Lernkurve, wenn man mehr verlangt als das OS von Haus aus mitbringt. Wenn man sich nicht darauf einlassen möchte, weil man eine 1-Klick-Lösung erwartet, dann wird man zwangsläufig zu dem Schluss kommen müssen, dass unRAID nicht deine Lösung ist. Willst du aber unRAID nutzen, werden dir hier sicher viele helfen, aber dann musst du dich auch darauf einlassen. Und damit meine ich klar kommunizieren was das Problem ist. Also Fehlermeldungen zitieren und/oder Screenshots posten. Dazu gehört es auch sich Backups zu erstellen und diese zu testen. Einfach damit du ein sicheres Gefühl dafür bekommst, wenn dir doch mal was kaputt gehen sollte. Ich glaube zb nicht, dass das Problem mit Filerun unlösbar ist. Ich mein selbst wenn durch irgendeinen Fehler die DB zerschossen wurde. Who cares. Backup vom Vortag einspielen und gut ist. Ähnliches kann dir schließlich auch bei Nextcloud oder jedem anderen Container passieren. War übrigens sogar schon der Fall als bei MariaDB irgendwas geändert wurde, was mit Nextcloud nicht harmonisierte. Ein Grund warum ich immer nur mit festen Versionen statt dem :latest tag arbeite. Sollen andere erstmal den "Betatester" spielen. Also lange Rede kurzer Sinn. Willst du es durchziehen, dann helfen wir gerne. Dann aber mehr Input bitte 🙂

Jo. Die Karten sind auch rückseitig verstärkt. Ob man den Kühlkörper wirklich braucht... schaden tut er jedenfalls nicht.

Try changing all Container paths from /mnt/user to /mnt/cache. Jellyfin paths can be changed to /mnt/disk1/Movie, /mint/disk2/Movie and so on. But this could need a full reindex. By changing to disk paths it avoids a lot of CPU load. But note: This fully bypasses your cache mover settings. So this is only useful for Shares set to only or no. I suggest to combine it with a free min space for alle shares and disks and pools!

No experience regarding this. 🤷

Deren Cache Einstellung auf Prefer ändern und den Mover anwerfen. Kann sein, dass du Docker und VM stoppen musst. @Ford Prefect bei only ist der Mover deaktiviert 😉

Hmm.. gute Frage. Ich habe zB den Xeon E-2146G. Der hat eine Base Clock von 3,5 Ghz und einen Turbo von 4,5 Ghz. Während die ganzen Container laufen komme ich nicht über 3 GHz: Er unterschreitet also bereits seine Base, während er was zu tun hat. Übrigens unterschreitet die CPU meine ich erst ihre Base Clock, wenn man den CPU Governor von Performance auf Powersave ändert. Das habe ich sogar mal gemessen. Das hat bei mir nur 1W Ersparnis gebracht. Also einen riesigen Einfluss scheint der Takt nicht zu haben. Er kann ja zB trotz Performance auch in die tiefen C-States wechseln. Das scheint also irgendwie unabhängig zu laufen. Zumindest weiß man bei einer T-CPU, das alles ab Werk in Richtung Strom sparen vorbereitet ist. Also optimal für "faule" Leute. Mein Hauptargument war ja eigentlich auch, dass früher die T-CPUs künstlich beschnitten waren und heute sieht es eher so aus als seien die T-CPUs, die einzigen, die nicht hoffnungslos ab Werk übertaktet sind. Zumindest ist das meine Theorie. Leider hat den T noch keiner gebenchmarkt: https://www.passmark.com/search/zoomsearch.php?zoom_query=13700t https://www.passmark.com/search/zoomsearch.php?zoom_query=13900t Gegenüber dem Non-K sind es ja gerade mal 2% Differenz bei Single Thread: https://www.cpubenchmark.net/compare/5060vs4992/Intel-i7-13700K-vs-Intel-i7-13700 Ich tippe beim T auf vielleicht 15% weniger Single Thread Leistung und dann wäre er wie gesagt immer noch schneller als jede andere CPU, die wir so üblicherweise empfehlen. zB ein W-1290P ist ja auch ein "Monster" und der ist deutlich schwächer: https://www.cpubenchmark.net/compare/5060vs4993vs3831/Intel-i7-13700K-vs-Intel-i5-13500-vs-Intel-Xeon-W-1290P Also ich werde das in jedem Fall mit der T-CPU machen. Mich reizt das total. Aber das Board... Asrock kündigt schön an und dann passiert wieder lange Zeit nichts. 😒

Eben nicht. Die takten alle auf so 800 MHz. Tatsächlich publiziert Intel das nicht bei den technischen Daten, aber es gibt in Wirklichkeit drei Frequenzen: Minimum, Base und Boost (Turbo) Kann man wie folgt auslesen: ~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq 800000 800000 800000 800000 800000 800000 800000 800000 800000 800000 800000 800000

Hängt vom Mainboard ab. Mal hat es einen Einfluss mal nicht. Manchmal hängt es auch von den verwendeten USB Buchsen ab. Da hilft tatsächlich nur ausprobieren.

Jede CPU taktet runter, wenn sie nichts tut. Check mal mit powertop die Frequency Seite, dann siehst du das. Also das spielt tatsächlich keine Rolle.

30 MB/s nehme ich an. Also 240 Mbit/s. Wenn Hair Pinning aktiv ist, ist die Geschwindigkeit eingeschränkt, da das quasi 2x durch die Firewall der Fritz!Box geht (raus/rein und nein sieht man nicht im Internetmonitor). Bei einem Upload über den Browser komme ich dabei auf 500 bis 600 MBit/s (laut Windows Taskmanager und Unraid Dashboard). Ebenfalls mit einer 7590.

Auf einen Pool klicken

Das ist nur in bestimmten Szenarien ein Muss. Zb wenn man IPv6 haben will oder einen lokalen DNS nutzt, um für die Domains lokale IPv4 auszugeben, die direkt auf den Proxy verweisen. Viele machen aber nur IPv4 und nutzen da einfach das Port Forwarding vom Router. Tatsächlich empfehle ich aber auch unRAID auf TB 5000/5001 zu ändern. Dann hat man schon mal die Basis für jede Variante geschaffen. Diese Installationsmethode gibt es nicht in der Dockerwelt. Soll heißen du hast aktuell Nextcloud UND die Datenbank UND das Zertifikat auf dem selben Betriebssystem liegen. Bei Containern hat man den Proxy, der die Zertifikate verwaltet, die Nextcloud Applikation und die Datenbank in jeweils anderen Containern. Daher ist es ein guter Hinweis erstmal mit dem Proxy zu "spielen". Schafft man es mit seiner öffentlichen IPv4 die Willkommensseite von NPM öffnen, hat man schon einen Teil abgearbeitet. Dein kostenpflichtiges Zertifikat ist dann übrigens überflüssig. NPM nutzt einfach kostenlose von Lets Encrypt. Dein wirkliches Problem wird aber der Datentransfer werden. Du musst erstmal verstehen in welchen Verzeichnissen der Container welche Daten ablegt. Also am besten installiert man Nextcloud neu. Dann schaut man sich die Struktur an und wenn den Überblick hat, stoppt man den Container, löscht die vorhandenen Daten und spielt alles von seinem Backup ein. Bei der Datenbank entsprechend auch. Zb über den Adminer Container könnte man das Backup dann auch per Browser einspielen. Achte bei der Installation des Containers darauf, dass der die selbe Version hat wie deine aktuelle Installation. Also statt nextcloud:latest zb Nextlcoud:23.0.2

Gut zu wissen wäre es, ob es das eine oder das andere war. Auch empfehle ich dir das Array in den Wartungsmodus zu versetzen und alle Disks zu reparieren. Auch alle Pools scrub + balance machen. Crashes können durchaus mal das Dateisystem beschädigen und dann erst Recht Crashes verursachen

Verschaffe dir einen Überblick vom Inhalt der jeweiligen Disks, starte den Check und schau dann während dem Check erneut drauf, wenn du meinst dass sie weg sind. Übrigens versteht die Parity gar keine Dateien, sondern nur XOR RAW Daten, weshalb das noch weniger Sinn macht. Würde man mit der Parity eine Disk wiederherstellen, wäre die entweder komplett kaputt oder komplett wieder da. So etwas wie "da fehlt ein Ordner" geht technisch gar nicht. Und ein Share ist ja nichts anderes als ein Ordner im Hauptverzeichnis einer Disk. Oder redest du gar nicht von einem Parity Check, sondern von einem Disk Rebuild?! Wo genau "verschwinden" deiner Ansicht nach überhaupt die Shares? Also sind die Ordner wirklich physisch von der entsprechenden Disk weg? Oder gar von allen (es gibt ja Verteilungsregeln)?!

Dein Problem ist nicht das Netzteil und die Effizienz, sondern die Instabilität von USB. Das taugt nicht im Array. Ansonsten gilt grob, dass du pro HDD 1W mehr Verbrauch über USB hast. Die Netzteile sind ja klein und effizient.

Wenn du den Film nur in 4K hast und du willst ihn z.B von unterwegs schauen dann bleibt er ja nichts anderes übrig als ihn zu transcodieren. Bei Gaming oder Videoschnitt ja, aber nicht auf einem NAS.

Ist der i5 K nun ein echter Raptor Lake geworden oder doch nur ein Alder Lake Refresh wie die ganzen i3 und kleineren i5? Das von dir gewählte Corsair RM550x ist das alte ineffiziente, nicht das neue 2021. Die RAM Auswahl ist Banane. Nimm einen 32GB. Dann kannst du später auf 128GB aufrüsten. Man kann nie genug RAM haben (Plex RAM Transcoding, Upload Caching, Nextlcoud Bildkonvertierung, VMs usw) Das Netzteil dürfte auch nicht in das Gehäuse passen. Hast du wirklich so einen 19 Zoll Monsterschrank zu Hause? (Einbautiefe)

Ok, dann sag mal wie du das auswertest und ich mache es dir nach ^^

Das macht keinen Sinn, weil der Parity Check die Parity korrigiert und nicht das Array.

Nimm Visual studio code

Der Papierkorb einer meiner User hat eine Größe von über 300GB. Laut Doku werden gelöschte Dateien nicht dem User-Limit angerechnet: https://docs.nextcloud.com/server/latest/user_manual/en/files/deleted_file_management.html Aber sie werden entsprechend dem eingestellten Kontingent nach 30 Tagen gelöscht, wenn der Papierkorb mehr als 50% des Kontingentwertes überschreitet: Problem: Alle meine User haben ein unendliches Kontingent. Vom Gefühl her würde ich sagen, dass man lieber einen festen Wert eintragen sollte, damit der Papierkorb nicht immer weiter wächst. Zusätzlich dachte ich daran, das hier zu machen: 'trashbin_retention_obligation' => 'auto,30', https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/trashbin_configuration.html Das sollte denke ich bedeuten: Lösche, wenn der Papierkorb mehr als 50% des Kontingents belegt und grundsätzlich alles was länger als 30 Tage im Papierkorb ist. Und das in Kombination mit einem grundsätzlichen Kontingentlimits für alle User. Ich denke ich starte erst mal mit 200GB pro User (der Papierkorb darf also 100GB groß sein). Was meint ihr? EDIT: Ich habe das jetzt mal so umgesetzt: Die 200GB habe ich über das Standardkontingent gesetzt: Mal sehen wann der Papierkorb kleiner wird: # du -hs /mnt/cache/appdata/nextcloud/data/*/files_trashbin 315G /mnt/cache/appdata/nextcloud/data/a/files_trashbin 0 /mnt/cache/appdata/nextcloud/data/b/files_trashbin 0 /mnt/cache/appdata/nextcloud/data/c/files_trashbin 18M /mnt/cache/appdata/nextcloud/data/d/files_trashbin

EDIT: Hier geht es weiter: https://forums.unraid.net/topic/129632-homeassistant-container-und-externe-datenbank-bzw-die-umstellung-mit-import/#comment-1183485

Also dass alle Datenbanken kaputt gehen ist nicht normal. Klingt nach defektem RAM oder Datenträger würde ich sagen.