hawihoney

PCIe 2.0 hat meines Wissens 5 Gb/s pro lane. Ich gehe davon aus, dass Du SAS/SATA mit <= 6 Gb/s pro lane im Einsatz hast. Was PCIe 3.0 theoretisch kann sind dann "nur" noch 20 % oben drauf bezogen auf Deine weitere Hardware. Das ändert sich rapide mit 12 Gb/s SAS bei entsprechender Hardware. Soweit die Theorie. Ob 11 Stunden oder 13, spielt das wirklich eine Rolle? Zumal man ja weiter arbeiten kann. Ich verhandle gerade mit mir selbst einen 17 % Rückgang in der Performance bei Parity-Checks bzw. -Rebuilds. Denn nur dabei spielt es wirklich eine Rolle. Ich könnte ~ 20 W einsparen - was nicht so wichtig wäre. Aber ich würde 2 sinnvoll zu nutzende PCIe 3.0 x8 Slots freimachen können - weiß nur noch nicht wofür 🤔

Ich betrachte das als durchaus normal. Hier 12 TB Platten: Hier 18 TB Platten: Meine Historien zeigen die Realität an aktueller Server-Hardware. Ein dritter Server mit 6 TB Platten liegt bei 13 Stunden. Das kann um ein Dutzend MB/s rauf oder runter variieren - aber es passt wie Du siehst. Die Grenze ist wohl eher der Parity-Check mit zwei Parity-Platten sowie den genutzten Festplatten-Modellen und deren Anbindung (SATA/SAS 6/12), als die Differenz zwischen PCIe 2.0 vs. 3.0.

Der HBA hat einen PCIe 3.0 x8 Anschluss, das Board hat einen PCIe 3.0 x16 Slot. Diese HBAs sind von Hause aus im IT Modus. Da muss man üblicherweise nix konfigurieren. Solche x8 HBAs haben im Zusammenspiel mit der genannten CPU genug Bums um eine komplette Backplane mit 24 Platten ausreichend zu versorgen (2x 4 Lanes). Es bedarf mehr Details von Deiner Seite: Wie groß sind die Platten und wie viele hängen am HBA? 1x oder 2x Parity - viele vergessen das die zweite Parity kein Duplikat der ersten ist sondern eine weitere binäre Kalkulation erfordert,

Die Parity-Festplatten enthalten kein Dateisystem und müssen nicht formatiert werden. Die erste Parity-Festplatte (P) enhält an jeder Bit-Position eine boolsche Berechnung der Bits aller Daten-Platten an der selben Bit-Position (XOR even). Von außen betrachtet enthalten Parity-Festplatten nur Daten-Müll. Dieser Daten-Müll hilft aber im Katastrophenfall beim Rekonstruieren einer beliebigen defekten Daten-Platte im Unraid-Array. Nur bei exakt einer Parity-Platte und einer Daten-Platte kann man die Parity-Platte theoretisch lesen - da diese Konstellation zufällig ein RAID-1 ergibt. Also, einfach machen lassen. Ich empfehle ein wenig Hintergrund Lektüre: https://docs.unraid.net/unraid-os/manual/what-is-unraid/#parity-protected-array

Ich würde erst mal nach dem Problem suchen. Zum Beispiel hier: /var/log/syslog bzw. durch das Posten der Diagnostics.

Für durchgängigen Betrieb ohne krasse Anforderungen an die Performance führe ich einfach Folgendes beim ersten Start des Servers in einem User Script aus. Ist jetzt nicht unbedingt der Knaller - aber sicher: #!/bin/bash #arrayStarted=true #clearLog=true # https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt /etc/rc.d/rc.cpufreq powersave # Pruefung # cpufreq-info -o # watch -n3 "cpufreq-info | grep 'current CPU'"

Vielen Dank für Deine Ausführungen. Du hast Recht. Das System existiert in dieser Form seit 2019 und besteht aus 1x Unraid Host, 2x Unraid VM, 72x Festplatten zzgl. 2x NVMe Cache. Da ausschließlich Unraid-Pools (AKA Unraid-Arrays) zum Einsatz kommen, hält sich der Strom in Grenzen da wirklich immer nur die benutzte Platte hochfährt. Daher rührt auch meine Abneigung gegen User-Shares. Die haben in dieser Dimension nicht wirklich sinnvoll geklappt. Ich habe die ausschließliche Kontrolle über das System und ich biete das in der Familie an. Was Parity-Checks oder Rebuilds angeht, da bin ich wirklich entspannt. Ich schreibe in die WhatsApp Gruppe "Maintenance" und die halten die Füße still. Ansonsten wären deren Trillionen Poser Fotos mal weg Mir ist eben im Restaurant aber noch eine vierte Alternative eingefallen, Dabei gehen zwei Kabel an den ersten Storage und nur von diesem via Expander 1 Kabel an das zweite Storage. Ich müsste dann zum neuen HBA nur noch ein zusätzliches Slotblech kaufen, da dann drei Buchsen benötigt werden. Die Backplanes von Supermicro sind wirklich genial. Meine billige EL1 Variante hat kein Ausfall-Feature. Das brauche ich auch nicht. Die drei Anschlüsse können aber wahlfrei als Eingang oder Ausgang belegt werden. Das regeln HBA und Backplanes intelligent aus. Ich bin mal gespannt in welcher Form multiple Unraid-Pools implementiert werden. Im optimalen Fall hätte ich dann 3x voll bestückte Unraid-Pools im Host und könnte die VMs und die SMB Connections eliminieren. Die VMs fressen ja auch noch ein wenig Strom - obwohl es auf den Strom bei uns wirklich nicht ankommt. +---------------+ +--------------+ ! Host HBA -+-------+ Host intern ! ! LSI 9400-8i8e-+-------+ Backplane ! ! +----+ ! BPN-SAS2-EL1 ! ! +--+ ! ! ! +---------------+ ! ! +--------------+ ! ! ! ! +--------------+ ! +--+ Storage 1 ! +----+ Backplane ! ! BPN-SAS2-EL1 +--+ +--------------+ ! ! +--------------------+ ! ! +--------------+ +--+ Storage 2 ! ! Backplane ! ! BPN-SAS2-EL1 ! +--------------+ Hier ein Bild der Backplane. Die drei Anschlüsse habe ich in rot, den Single Expander (EL1) in blau markiert. Backplanes mit Ausfall-Sicherheit besitzen auf der linken Seite drei weitere Anschlüsse für einen weiteren HBA, eine zweite Verbindung zu den weiteren Storages sowie einen zweiten Expander. Dann kann auch mal ein HBA ausfallen ohne das man es merkt.

Zu 2 und 3: Spricht nichts dagegen. Die meisten Leute haben Fix Common Problems nicht installiert. Die würden diesen Hinweis nicht zu sehen bekommen und wären wahrscheinlich glücklich - AKA was ich nicht weiß ... Zu 1: Da bin ich überfragt - kein ZFS hier. Grundsätzlich ist aber /mnt/user/ kein "richtiger" Ordner sondern das Ergebnis des FUSE Systems. Dort landen - sofern User Shares aktiviert sind - alle Wurzelordner der Array- und Pool-Disks. Hast Du denn die Hinweise aus dem CHANGELOG zu 6.12.x bzgl. importieren von ZFS Pools beachtet und ausgeführt?

zu 1+2: Lautet der Pfad wirklich usr oder user? zu 3: Es gibt zwar bei Erstinstallation Standardpfade, diese sind aber nicht erforderlich. Hauptsache die von Dir verwendeten Pfade werden konsequent und durchgängig genutzt: https://docs.unraid.net/unraid-os/manual/shares/user-shares/#default-shares Standard Unraid sind: /mnt/user/appdata/ /mnt/user/system/ /mnt/user/domains/ /mnt/user/isos/ /mnt/disk*/ /mnt/<poolname>/ <--> /mnt/user/<poolname>/ Standard durch Unassigned Devices plugin: /mnt/addons/ /mnt/disks/ /mnt/remotes/

Du hast auf eine Disk kopiert. Jetzt mit dem User Share zu arbeiten kann gefährlich sein. Niemals Disk und User Share beim Arbeiten mischen. Datenverlust kann passieren. Obwohl ich weiß was ich mache würde ich das nie tun. In dem User Share könnte ja bereits Inhalt von anderen Disks sein - also nicht nur das zuletzt kopierte von Disk1. Es gibt mehrere Möglichkeiten - abhängig von Deinem Wissensstand: 1.) Lösch auf dem selben Weg wie Du zuvor geschrieben hast. Also das zuvor kopierte von Disk1 löschen und dann komplett neu auf den gewünschten User Share schreiben. Das gilt nur wenn Du noch die ursprüngliche Quelle - das Original des Kopierens - hast. Das würde dann die von Dir eingestellten Füllgrade beachten. Dieser Weg ist sicher aber dauert länger. 2.) Mit dem Dynamix File Manager, oder dem "mc" auf der Konsole, die zuvor kopierten Daten von Disk1 auf eine andere Disk (nicht User Share!) verschieben. Sollte der Inhalt zu viel für eine zweite Platte sein, dann musst Du halt in Häppchen auf unterschiedliche Disks verschieben. Das geht erheblich schneller, man muss aber mehrfach schauen was man da gerade macht. Solange Du nicht /mnt/user/ und /mnt/disk*/ in Operationen bzw. Arbeitsschritten vermischst kann eigentlich nicht viel passieren. Im Übrigen steht das user in /mnt/user/ nicht für irgendwelche "User" sondern für "User Shares". Beispiel mit dem mc. Du willst von einer Disk auf eine andere Disk verschieben. Es würde im mc nach Drücken der F6 Taste (RenMove=Verschieben) der Ordner 09 von Disk17 unterhalb von Disk1 erscheinen. Da 09 ein Wurzelordner auf dieser Disk würde, würde 09 automatisch auch ein User Share:

Seit in den "Gerüchten" die Möglichkeit mehrfacher Unraid Pools erwähnt wurde, treibt mich die im Header genannte Frage um. Zunächst zu meinem System. Es besteht aus drei Server-Gehäusen (Supermicro SC846) wobei zwei dieser Gehäuse als Storages (ohne Motherboard, etc) fungieren. Es handelt sich also strenggenommen um nur einen Server. Bisher gibt es für jede Backplane einen eigenen HBA die mit jeweils zwei Kabel verknüpft sind (SFF-8644/SFF-8088). In Unraid gibt es für jede Storage eine eigene Unraid VM. Der Zugriff über die Gehäuse hinweg läuft leider über SMB da die HBAs an die Storages durchgereicht sind. 1.) Hier der aktuelle Zustand (jede Backplane ein HBA): 3x HBAs im Host. Zwei Kabel zur internen Backplane. Je zwei Kabel zu den beiden externen Storages. +-------------+ +--------------+ ! Host HBA -+-------+ Host intern ! ! LSI 9300-8i-+-------+ Backplane ! ! ! ! BPN-SAS2-EL1 ! +-------------+ +--------------+ +-------------+ +--------------+ ! Host HBA +-------+ Storage 1 ! ! LSI 9300-8e +-------+ Backplane ! ! ! ! BPN-SAS2-EL1 ! +-------------+ +--------------+ +-------------+ +--------------+ ! Host HBA +-------+ Storage 2 ! ! LSI 9300-8e +-------+ Backplane ! ! ! ! BPN-SAS2-EL1 ! +-------------+ +--------------+ 2.) Alternative 1 (ein HBA, Nutzung der Expander auf den Backplanes der externen Storages): Ein HBA geht mit zwei Kabeln an die interne Backplane. Von dort geht ein Kabel zum ersten Storage und von dort ein Kabel an das zweite Storage: +-------------+ +--------------+ ! Host HBA -+-------+ Host intern ! ! LSI 9300-8i-+-------+ Backplane ! ! ! ! BPN-SAS2-EL1 +--+ +-------------+ +--------------+ ! ! +--------------------+ ! ! +--------------+ +--+ Storage 1 ! ! Backplane ! ! BPN-SAS2-EL1 +--+ +--------------+ ! ! +--------------------+ ! ! +--------------+ +--+ Storage 2 ! ! Backplane ! ! BPN-SAS2-EL1 ! +--------------+ 3.) Alternative 2 (ein HBA mit internen sowie externen Ports für alle Backplanes): +---------------+ +--------------+ ! Host HBA -+-------+ Host intern ! ! LSI 9400-8i8e-+-------+ Backplane ! ! +----+ ! BPN-SAS2-EL1 ! ! +--+ ! ! ! +---------------+ ! ! +--------------+ ! ! ! ! +--------------+ ! +--+ Storage 1 ! ! ! Backplane ! ! ! BPN-SAS2-EL1 ! ! +--------------+ ! ! +--------------+ +----+ Storage 2 ! ! Backplane ! ! BPN-SAS2-EL1 ! +--------------+ Zu beachten wäre, dass in den beiden Alternativen immer nur ein Kabel (4 Verbindungen) zu den Storages geführt wird, während derzeit jede Backplane in den Genuss von zwei Kabeln (8 Verbindungen) kommt. Ich halte den Performance-Verlust für nicht so tragisch da nur bei Parity Checks oder Disk-Rebuilds alle Platten angesprochen werden. Auf der anderen Seite spart man Strom für zwei HBAs. Ich bin eher der Software-Typ, Hardware kann ich Einiges aber nicht in den Randbereichen. Was würdet Ihr empfehlen? https://forums.unraid.net/topic/116379-vorstellung-die-cloud-der-großfamilie/

Ist das nicht eine Beta? 6.24 ist die letzte stable - zumindest gem. Hersteller: https://www.rarlab.com/download.htm

Hier die offizielle Beschreibung des manuellen Verfahrens: https://docs.unraid.net/unraid-os/getting-started/manual-install-method/

Hast Du diese Hinweise beim Upgrade beachtet? Es betrifft Nutzer mancher Router im Zusammenspiel mit dem Docker Subsystem. Die drei empfohlenen Änderungen stehen in folgendem Text: https://docs.unraid.net/unraid-os/release-notes/6.12.4/#fix-for-macvlan-call-traces

Das ist, wie ich vermutet hatte, eindeutig und eindeutig zu viel. Du hast ein Hardware Problem und das liegt auf dem Weg bis zur Festplatte. Kannst ja mal die SMART Werte aller Platten durchgehen. Wenn es eine gibt mit 0 Fehlern, dann kannst Du vielleicht die Anbindung eingrenzen. Das bringt natürlich nur etwas wenn es unterschiedliche Anbindungen gibt (Motherboard, Adapter, Backplane oder nicht, etc.). Positioniere Dich in den Ordner mit den SMART Dateien und ruf folgendes auf. Dann hast Du alle Werte der Platten auf einen Blick: grep "UDMA_CRC_Error_Count" *.txt

Das kannst Du selbst ganz einfach herausfinden: Guck in der ZIP Datei in den SMART Ordner und öffne die Datei der gewünschten Platte. Suche die o.a. Zeile mit den CRC Werten.

Guck mal in Deine syslog - die ältere. Die ist voll mit Lesefehlern und Device Resets. Es dreht sich um den Adapter und die Platte sdy. Die Platte hat extrem viele CRC Error - Verbindungs Problem. Nov 9 13:18:25 raider kernel: I/O error, dev sdy, sector 8315879856 op 0x0:(READ) flags 0x0 phys_seg 46 prio class 2 ... 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 3399

Keine Ahnung. Wenn ich aber Dein Screenshot oben anschaue, dann sind das doch keine Parity Sync Fehler sondern Schreib-/Lesefehler. Sind alle Platten SATA oder gibt es auch USB? Poste mal eine Diagnostics Datei. Ich will mal die SMART Werte von z.B. Disk1 sehen.

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: