hawihoney

Ich habe einfach zwei Pools mit jeweils einer XFS formatierten PCIe NVMe angelegt. Ein Pool ist das Ziel für KVM und Docker. Der andere Pool läuft zunächst ohne Funktion mit. Dazu habe ich ein User Script im User Script Plugin eingerichtet. Was dort drin steht hängt natürlich von den Anforderungen ab. In meinem Script werden nach und nach alle Container gestoppt, deren Daten auf den mitlaufenden Pool repliziert (rsync) und dann wieder gestartet.

Das hat etwas mit dem Gesamtkonstrukt Cache und dessen Historie zu tun. Traditionell wird der Cache nicht nur als schneller Schreibcache für das Array verwendet, sondern auch als Ablage für die Subsysteme Docker und KVM. Das Limit ist nur ein Schutz für diese. Mit dem neuen Multiple-Pools Feature ist das zwar nicht mehr ganz so wichtig, aber viele betreiben nach wie vor einen einzelnen Pool/Cache für all diese Daten.

Zunächst: Ich würde keine NVMe/SSD als Array Devices nehmen. Da gehen die Meinungen auseinander. Ich würde es aber nicht machen. Das Problem ist das fehlende Trim bei der Parity. Sind das beides PCIe Devices oder SATA/NVMe PCIe gemischt? Beim Schreiben: Nein, im Array (ohne Cache) bestimmt die langsamste Platte die beschrieben wird (inkl. Parity) die Performance. Bei nur einer Daten-Disk und genau einer Parity-Disk? Ja. Sie muss mindestens so groß sein wie die größte Daten-Disk. Bei nur einer Daten-Disk? Klar, wo sonst? Im Array übernimmt die Parity die Absicherung auch dieser weiteren Disk. Das Unraid Array ist ein RAID-4. Bei nur einer Daten-Disk und einer Parity-Disk ergeben beide dadurch "zufällig" ein RAID-1. Ab zwei Daten-Disks bleibt es ein RAID-4. Es handelt sich nicht um eine langsame Übertragungsleistung, sondern es liegt in der Natur des RAID-4. Jeder Schreibzugriff resultiert bei Standardeinstellung in drei Zugriffen. Somit hat das Array in etwas ein Drittel der Performance der langsamsten Platte. Alternative #1: Schreib-Cache verwenden. Alternative #2: Schreib-Tuning, resultiert allerdings in höherem Stromverbrauch, da alle Platten benutzt werden und nicht nur die eine Daten-Disk inkl. Parity. Das Zielsystem muss das von Dir gewählte Dateisystem der Platte verstehen können (zur Auswahl stehen Dir ReiserFS, BTRFS, XFS). Wenn Du Verschlüsselung in Unraid gewählt hast, klar. Sonst nicht.

Nur wenn auf die Daten-Platte geschrieben wird.

Hast Du Backups? Die Container bekommt man 1:1 wieder ans Laufen da deren XML Dateien auf dem Boot Stick gespeichert werden. Einstellungen und Daten innerhalb der Container können ggfs. weg sein. Kommt auf die Container an ...

Nein, selbst mit Docker auf dem Array läuft alles beim Parity-Check weiter. Wo liegt das Docker-System? Auf dem Cache? Was ist denn der Status des Cache jetzt während des Parity-Checks? Mach mal Screenshot von Main-Page bzw. poste mal Diagnostics. Die BTRFS Gurus werden sicherlich einen guten Rat haben ... Auf keinen Fall vorschnell formatieren.

This! Es hat sich gelohnt zwei XFS Single-Caches statt eines BTRFS-RAID zu betreiben und das nächtliche Replizieren selbst zu bauen. Mit BTRFS war mein System unerträglich oft offline. Nie wieder Scrub/Balance ...

It depends. PCIe connected NVMe drives handle >3000 MB/s quite easily. So Cache/Pool-Writes would utilize networking at that speed.

Es wird sicherlich viel ältere Platten geben, aber nur mal ein Beispiel aus meinem Altbestand: 9 Power_On_Hours 0x0032 052 052 000 Old_age Always - 42094 4 Start_Stop_Count 0x0032 096 096 020 Old_age Always - 4180 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 721 193 Load_Cycle_Count 0x0032 074 074 000 Old_age Always - 53275 #9 ist runter auf 52% durch die lange Laufzeit. Selbst die 721 Stromabschaltungen bei #12 zeigen noch 100%. Und die 4180 Spin-Ups/-Downs haben nur zu einer Reduzierung von 4% (=96%) geführt. Und die vielen Rückführungen in die Parkposition bei #193 sind auch nur auf 74% runter. Mach Dir keine Gedanken. Gerade die Platten in Unraid Arrays haben ein tief entspanntes Leben.

Meine Unraid Server laufen seit vielen Jahren. Früher habe ich die Server nachts runtergefahren. Damals hatte ich regelmäßig defekte Festplatten. Vor drei Jahren habe ich begonnen die Server durchlaufen zu lassen. Spindown Delay für alle Array Platten steht seit dem auf 15 Minuten. Seit der Umstellung ist nur eine einzige Festplatte ausgestiegen. Das Starten/Stoppen des ganzen Systems ist meiner Erfahrung nach eine erheblich größere Belastung als ein durchlaufender Server mit vielen Spin-Ups/-Downs.

Hier != Unraid? Hmm ...

Die klappen, garantiert. 4,5 Millionen Downloads alleine vom binhex Plex sprechen eine eindeutige Sprache. Vom Linuxserver Plex, dem Platzhirsch, kenne ich die Zahlen nicht. Wenn sie nur bei Dir nicht klappen, dann hat das einen Grund. Der liegt dann aber nicht bei Unraid.

Poste bitte mal einen Screenshot der Container Einstellungen. Dort hättest Du eine Pfad-Zuordnung (Path-Mapping) zwischen dem von Dir vorgesehenen Host-Pfad auf dem Server und dem gewünschten Container-Pfad vornehmen müssen. Das musstest Du bei Proxmox nicht machen? Haben die Container dort immer vollen Zugriff? Das wäre ja erschreckend.

Auf den SSD Cache natürlich. War das wirklich die Frage?

Ah, das meinst Du. Darüber gibt es bereits eine Anfrage im Community Applications Plugin Thread.

Keine Ahnung. Was aber immer ging war das:

Das sollte man auf keinen Fall tun. USB Verbindungen sind nicht für solche Anwendungsszenarien gedacht. Da muss bloß etwas mit dem Strom oder der Verbindung wackeln, dann markiert Unraid diese USB-Platte sofort mit einem Fehler, o.ä.. Da das Array dann trotzdem weiterarbeitet (wenn Parity-Platten existieren), bedeutet das, dass Du die Platte aus dem Array entfernen und anschließend die Parity neu aufbauen musst. USB-Verbindungen gehören weder ins Array noch in Pools. Ich weiß, das machen einige wenige. Die müssen dann aber auch mit dieser Entscheidung leben. Man nutzt USB-Verbindungen höchstens als temporäre Speicher, dafür sind sie designed.

Das gibt's doch nicht. Ich wusste bisher nicht, dass man da drauf klicken kann. Danke.

Vergiss es. Den Ablageort zu kontrollieren habe ich schon vor ein paar Seiten angeregt. Ich will das jetzt nicht mehr nachlesen, aber ich meine die Antwort war in etwa "will ich mich nicht mit befassen" oder "Unwichtig" oder so.

Ich habe hier sehr, sehr viel Hilfe von einfachen Usern gesehen. Leider traf diese Hilfe auf eine, meiner persönlichen Meinung nach, ausgeprägte Beratungsresistenz. Da sind die Helfenden am Ende machtlos. Hilfe einfordern, Vorschläge aber überwiegend von sich weisen (keine Zeit, keine Lust, muss anders gehen, ...) kostet im Grunde genommen beide Seiten nur Zeit und Energie. Wenn es die Möglichkeit gäbe, einen Thread entsprechend zu markieren, dann würde ich mir wünschen, dass dieser Thread als negatives Beispiel markiert wird, wie man nie, auf keinen Fall, unter keinen Umständen, an ein neues System heran gehen sollte. Dies von einem Unraid User seit 13 Jahren, der bis heute nicht weiß wofur br0 gut sein soll oder warum er drei Ethernet Kabel ins Motherboard stecken muss damit er keine Fehlermeldung bekommt. Unraid läuft hier trotzdem, immer, extrem stabil und mit einem sehr großen Funktionsumfang.

Nextcloud ausprobiert?

https://wiki.unraid.net/Documentation Ok.

Exakt diese Vorgehensweise wird mit ziemlicher Sicherheit zum Scheitern verurteilt sein. Deine Enttäuschung kannst Du dann aber nicht Unraid anlasten. Es ist vielmehr Dein eigenes Rezept für den Umgang mit neuen Techniken bzw. Systemen das hier hakt.

Nicht so hektisch. Genau das hatte ich geschrieben. Unraids Cache ist ein Schreib-Cache.

Ein beliebtes Missverständnis. Was man gemeinhin als Cache bezeichnet ist der Unraid Cache eben nicht. Der Unraid Cache (bzw. Pool) ist, wenn man will, u.a. ein Schreib-Zwischenspeicher für neue Dateien und Ablageort für die von mir genannten Teile (Docker, Container, ...). Er ist aber nur beschränkt ein klassischer Lese-Zwischenspeicher. Also pack auf die M.2 NVMe die Docker/KVM Subsysteme plus deren Erzeugnisse (Container, VMs) und, wenn Du willst, den schnellen Schreib-Zwischenspeicher für User-Shares, der neue Dateien nachts aufs langsamere Array verschiebt. Oh, da irrst Du gewaltig. Plex legt zusätzlich zu seiner SQLite Datenbank unfassbar viele Verwaltungsdaten in Ordnern und Dateien ab. Wenn die langsam gelesen werden, dann hast Du keinen Spaß. Plex belegt auf meiner M.2 NVMe 200 GB nur mit seinen eigenen Dateien und Ordnern. Wohlbemerkt, das ist nicht der eigentliche Content sondern nur Verwaltungsdaten von Plex selbst.