hawihoney

Hab den Satz nicht verstanden ABER bei einem Parity-Check wird nur die Parity geändert. Die Daten-Platten haben immer Vorzug. So muss das auch sein.

Die Garantie kann Dir niemand geben. ABER: Der Ablauf der vier Operationen beim Schreiben fängt immer mit der Datenplatte an. Denn erst nach Kenntnis des beschriebenen Blocks auf der Daten-Platte kann der gleiche Block auf der Parity-Platte beschrieben werden. Zudem haben moderne Dateisysteme eine Art Transaktions-Log, das beim nächsten Boot abgearbeitet wird und nur vollständige Änderungen aufspielt. Lass einfach die Korrektur der Parity zu, damit das Array in sich schlüssig wird. Was mich nur nervös machen würde sind die über 20.000 Sync Fehler. Das ist für einen simplen Stromausfall viel zu viel. Jeder Schreibvorgang wird nämlich mit minimalem zeitlichem Versatz in der Parity abgebildet. Deshalb meine Fragen nach der Vergangenheit oder CRC-Fehlern. Hattest Du mehr als einen Stromausfall, o.ä.

Just try with these two settings reversed and MACVLAN. Worst that can happen is a crash within 24 hours. That would mean you are affected by MACVLAN crashes. AFAIK this is a docker problem. I am through with this and have to live with 10-15 sec delay currently.

These two are the problem. This workaround was recommended in 6.12.x for users experiencing "MACVLAN" crashes. You don't need them if you are a.) on IPVLAN or b.) didn't experience MACVLAN crashes or c.) you are no user of routers like Fritzbox in Europe.

Das Thema ist hier im Forum bestimmt schon 1000x hinterfragt worden: 1.) Nein, Unraid lässt nicht erkennen welche Dateien betroffen sind. Man sieht im syslog nur Tracks/Sektoren - denn nicht alles auf einer Festplatte gehört zu einer Datei (Metadaten. Verwaltungsinformationen, ...). 2.) Wenn man sich nicht sicher ist, dann spielt man ein Backup zurück. 3.) Allerdings scheinst Du nur gelesen zu haben (CRC Check) - das erzeugt keine neuen Dateien. Vermutlich hast Du das Problem schon länger oder etwas anderes hat massiv Daten geschrieben (25000 Sync Errors ist extrem viel). Schau Dir mal die SMART Werte der Platten an. Hast Du CRC Fehler? 4.) Es ist unerheblich ob eine Parity-Platte oder eine Daten-Platte betroffen ist. Wenn man kein Backup hat, dann bleibt einem nichts anderes übrig als den Parity-Check korrigierend laufen zu lassen. Die Parity-Platte muss zu den Daten-Platten passen. Durch Deinen nicht-korrigierenden Parity-Check hast Du nämlich im Moment folgendes Problem: Parity- und Daten-Platten passen nicht mehr zueinander. Wenn jetzt eine Daten-Platte ausfällt, dann wird diese garantiert mit Müll beschrieben.

Spielt denn beim Backup die Geschwindigkeit so eine große Rolle? Ich hab ein paar "Samsung Portable SSD T7" für diese Fälle. Die sind schnuckelig klein und passen in die Jackentasche. Die hänge ich einfach an den Server und starte einen rsync Job innerhalb eines User Scripts. Klar, das sind SSDs, aber von den NVMe Frickelgehäusen hatte ich eines mal in Betrieb, das war einfach nur Schrott. Die Samsung baumelt während des Backups zufällig vor dem Lüfterausgang des Gehäuses. Das kühlt die auch noch wunderbar runter: Und guck Dir mal die Vergangenheitswerte an (Data units read/written). Da wurde in der Summe ein PB bewegt. Die läuft und läuft und läuft ... Hier die Details zum Modell: Bzgl. 970 Evo Plus. Von denen habe ich zwei im Server. Einmal täglich synchronsieren die sich. Hier das Ergebnis des letzten Sync-Jobs. Nicht vergessen, da wird viel gelesen und geschrieben - also nicht kontinuierlich geschrieben. Dafür ist die Performance excellent:

Das ist so nicht korrekt. Das Verfahren ist bei allen Konstellationen identisch. Nur bei der oben genannten Konstellation führt das Verfahren zufällig zu zwei identischen Platten. Unraid nutzt zur Kalkulation des Parity-Bits "XOR-even". Das Ergebnis aller Bits aller Daten-Platten an der Bit-Position muss immer even sein, das Parity-Bit wird zur Korrektur gesetzt. https://docs.unraid.net/legacy/FAQ/Parity/#how-parity-works 0101 Daten-Platte XOR 0011 Parity-Platte = 0110 Das Ziel ist even(0). 0=0, 1=1 - nur die beiden äußeren werden even. Somit identische Bits in beiden Platten.

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.