DataCollector

Im UEFI Bootscreen des PC oder vor, oder nach dem unraid Auswahlmenü? Schwarzer Bildschirm oder eine Meldung, die andeutet, daß UEFI nicht sfindet? Könntest Du von dem Zustand vieleicht ein Bild machen und hier bereitstellen und ggf, mitteilen ob Du (der PC) ein paar Minuten in dem Zustand verharrt ist? Ist Dein System UEFI oder CSM? Wie heißt der Name des EFI Verzeichnisses auf dem USB Bootstick? Hast Du nach dem Update auch wirklich lange genug gewartet mit dem Neustart, daß der Stick auch wirklich korrekt (und vollständig) geupdatet wurde? Wenn es vorher ging und hinterher nicht mehr könnte es sein, daß die zu schreibenden Dateien (auf einem langsamen USB Stick) noch nicht vollständig vom USB-Stickkontroller geschrieben wurden, bevor der Neustart initiiert wurde. Hast Du mal mit einem anderen Stick eine 7.1.0 Unraidversion erstellt und versucht die zu booten (nachdem Du das EFI Verzeichnis darauf korrekt eingestellt hattest)? Bootet die sauber in die Testversion durch oder bleibt die an der selben Boot-Stelle hängen? Ansonsten könntest Du auch (nachdem Du alles vom Stick gesichert hast) evtl. den alten USB Bootstick löschen mit der 7.1.0 ZIP https://docs.unraid.net/unraid-os/download_list/ den Stick sauber neu machen und Dein altes Config Verzeichnis drauf schreiben.

Was heißt "bootet nicht mehr"? PC bleibt dunkel und versucht niocht mal zu booten? PC versucht zu booten, findet aber den USB Stick nicht? PC findet und startet den USB Stick doch nach dem Auswahlmenü passiert nichts mehr? PC findet und startet den USB Stick und der Bootvorgang bleibt mitten in den Meldungen stehen? PC gibt Rauchzeichen? Bestimmt, aber: Etwas genauer wäre hilfreich um vielleicht Dir helfen zu können.

Das hängt (für mich) von Größe und Wert (und Technik) der bestehenden USB Festplatten ab. (Will sagen, man weiß von Deiner Situation/Hardware zu wenig). Ich würde bevorzugen: Alles komplett neu/anders. USB Laufwerke nicht übernehmen. Wenn man aber dann einen Satz 24TB festplatten als SATA neu kauft und einbaut und dafür dann mehrere 24TB ext. USB festplatten ausmustert wäre mir das zu teuer. Da würde ich dann schauen ob ich die 24TB USb nicht shucken kann und die direakt als SATA nutze. Sollte es sich alt um einige der kleinen WD 2,5inch Modelle mit fest aufgelöteter USB Schnittstelle handeln ist das Shucken dort sinnlos, weil ,man die nicht pere SATA direkt anschließen kann. Die Konfiguration ist ja auch dem USB Bootstick. Die brauchst Du eigentlich nicht zu ändern.

Wenn ein großer Datentransfer nicht durch USB parity gebremst wird und Du die NVme SSD(s) vielleicht als Pool und nicht im Array nutzt hast Du wohl die besten Chancen, daß das System auf dem Web noch erreichbar sein könnte. Aber Wundser würde ich dennoch nicht erhoffen, wenn Du bei Schreiboperationenn ggf. auch den Ram auslastest. Vielleicht den Ramcache verringern, damit mehr Ram für WebGUI und normaklen Betrieb übrig bleibt (sobald Du Daten ins System rein schreibst).

Ja, da die CPU sowieso nur "PCI-Express-Version 2.0" beherrscht, ist das also NVMe mit 500MBit/s pro Lane. SATA ist schneller. Es kristallisiert sich immer mehr (mit jedem Stückchen nachgereichter Info) heraus, warum die Kiste in die Knie geht.

Solange man keine Bremse (wie Deine ursprüngliche USB Parity) einbaut: nein. Wenn man das Array aber durch irgendwelche (nicht empfohlenen) exotischen Konfigurationen bremst macht es eben sin, das dann ja leider doch wieder verlangsamte Array mit einem Cache beim direkten Schreiben zu 'umgehen'. Vielleicht solltest Du überlegen sowieso das Array zu umgehen und die NVMe SDs direkt als Pool einzzusetzen (seit unraid 7.x kann man ohne Array konfigurieren). Dann hast Du wenigstens auch noch Trim. Der Cache word benötigt (oder sagen wir besser: "ist sehr sinnvoll"), wenn das Array bei benutzun ausgelastet ist (weil es ggf. durch eine Flaschenhals augebremst wird). Da der Futro nicht unbedingt sehr viel RAM hat, werden Schreiboperationen von "großen dateien" auch nicht nennenswert durch den Ranmcache abgefangen. Somit schlägt ein langsames Array eben schnell zu. NVme SSD sind in der Regel sehr schnell. Die allein sind hier ja auch nicht das Problem. Das Problem entsteht mutmaßlich eben durch die USB Parity. Und ja, der Futro hat ja allerhöchstens USB 5GBit/s (3.0/3.1 gen1/3.2 gen1).

Die Samsung 990Pro NVMe ist hier schon mal negativ aufgefallen. Die würde ich jetzt vielleicht nicht nehmen (wenn ich neu kaufen würde). Diverse WD NVMe SSD sind aufgefallen, weil sie niedrige Stromsparzustände verhindern. Das betrifft nicht alle Modelle, aber ich bin zu faul mir die betreffenden Modelle zu merken. Deshalb mache ich bei unraid einfach einen großen Bogen um alle WD (Sandisk) NVMe SSD.

Ich schätze, die CPU schluckt etwas mehr als meine I3. 15-20W schätze ich idle. (Für das ganze System)

Leider wissen wir nicht viel über sein System. Bei 2x NVMe im Array vermute ich, daß er gar keinen Pool/Cache verwendet und genau dadurch seine stockendne Anwendungen kommen. Wenn alle sim Array läuft und das Array von "USB (unbekannter Geschwindigkeit) Parity" gebremst wird, ist es abzusehen, daß Schreiben großer Dateien im Array auch die Docker blokciert (die ja auch dort liegen). Deshalb hatte ich ja auch vorgeschlagen das einfach durch zufügen eiens SSD Caches/Pools zu entspannen.

Hast Du das alles schon? Wenn nicht: ich würde 2x16GB Ram nicht nehmen, sondern 1x 32GB. Damit ist man bei zukünftigen Aufrüstungen flexibler und muß ggf,. die 2x16GB Riegel nicht entfernen/wegwerfen/verhökern... Wenn Du mit SSD NVMe SSD meinst, ja, dafür sind 2 M.2 Slots vorhanden. Wenn Du mit SSD SATA SSD meinst: Das Board selber hat 4 SATA Ports. Eine SSD sollt ebvorzugt aan die onboard Anschlüsse gestöpselt werden. Standardempfehlung. bequiet BN341 (=ATX, wenn es passt) in das Fractal Design Node 804 soll ATX passen. In das N4 leider nicht. Nackt idle vermute/schätze ich die Kombination minimal unter 20W. In Benutztung/unter Last (mit spindown HDDs) etwas höher.

Ich würde gleich 1 oder 2TB nehmen und das dann (wenn Ausfallsicherheit ein Thema ist) als Pool mit Raid1/Mirror zfs (also 2 x 1-2TB) nutzen. Ich hatte es zumindest so verstanden, daß es (auch) um "große Dateien" geht, da sollte man dann auch Platz für frei haben.

jemand, der sein Array mit einer USB Parity betreibt. Ja, er hat 2 NVME SSD im Array und er hat wohl eine SSD per USB als Parity und gen au da bremst das USB ja. Sein Problem liegt ja da, daß er makl eben große Dateien ins unraid schreiben will und dann das System eben stockt. Ich ich gehe eben davon aus, daß die SSD per USB das Problem ist, weil bei der Parity ja alles mindestens 2mal durch den selben Flaschenhals muß. Ob die SSD an USB nun NVMe oder SATA ist, ist dabei unbekannt. Eher der Fehler im Aufbau.

... nicht, wenn eine USB Anbindung hier blockiert, weil alle Datren schreibend 2mal durch den USB Flaschenhals müssen (lesen und schreibend wegen der Parity dort). Wir wissen nicht einmal wie schnell seine USB Anbindung ist. Ich hatte schon mitbekommen, daß er SSDs im Array hat, aber ohne zu wissen, wie der Rest aussieht gehe ich davon aus, das seine Scheribvorgänge per USB so viel Last/Blockierung erzeugen, daß das System eben ganau das macht, was er ja erlebt. Und ein abfangender Pool/Cache, der die Schreiblast zu Stoßzeiten aufnimmt, sogrt dafür, daß die Schreiboperationen im Array in lastarmen Offzeiten abgewickelt werden kann (wenn man den Mover entsprechend geschickt einstellt). Erwähnte ich schon, daß ich das Problem in der Parity an USB sehe und ein puffernder Pool/Cache das abfangen könnte? Hm,. ich glaube auch in der Richtung erwähnte ich es hier schon 😉 Das wollte ich damit andeuten. Wenn dann noch USB 2.0 (480MBit/s) oder 3.0 (5GBit/s) ins Spiel kommen wird es echt mies. ...wenn man es nicht per USB anbinden würde... Sie müssen nicht gleich, sein, aber Größenunterschiede machen sich ggf. bemerkbar.

Parity sollte immer die schnellste Disk im Array sein. USB ist im Array (und Parity ist ja im Array) nicht empfohlen. [Es ist möglich, aber ggf. riskant] SSD sind im Array nicht empfohlen (auch, weil kein Trim unterstützt wird) [aber es ist möglich] USB ist vom Protokoll her etwas instabiler und etwas langsamer (man bekommt nur eine sehr begrenzte Menge der eigentlich möglichen IOPS durch USB gereicht, wobei eine native Anbindung NVME an PCIe weitaus mehr schaffen kann. Gerade die Parity steht etwas stärker unter Schreiblast, als die Daten enthaltenden Datenträger im Array. Gerade die Parity über USB anzubinden, wenn die anderen Datenträger NVME direkt an PCIe Sind, sehe ich persönlich als eine ungünstige Konstellation an.). Grundlegend funktioniert es, aber Du erlebst in Deiner Erfahrungen einen der Nachteile, wenn man entgegen der üblichen Konstruktionen das System doch sehr 'bemerkenswert anders' aufbaut. Ich würde als Parity den schnellsten Datenträger im Array verwenden und den nativ anbinden. USB wäre zwar nicht meins, aber wenn, dann schon eher einen Daten tragenden Datenträger per USB. Achja, soweit ich las (oder eben nicht las), scheinst Du keinen Pool als Schreibcahe zu nutzen: Das wirkt sich natürlich auch aus, wenn Du das System voll schreibst. Wenn ich direkt große Datenmengen (aka große Dateien) ins Array schreibe (und dabei auch den Ram Cache auslaste) brechen meine System auch ein. Dafür hat man ja einen flotten SSD Pool, den man dann als Cache vorschaltet.

Das ASRock N100M ist vor Wochen im Preis angestiegen. Leider. Der kleinere Zwilling ASRock N100DC-ITX (90-MXBLM0-A0UAYZ) mit einer minimal schlechteren PCIe Verteilung und einer begrenzten Stromversorgung onboard ist weiterhin für unter 130 Euro zu haben. Basierend auf dem Preissprung des ASRock N100M (den es ja schon vor Wochen vollzogen hat) hege ich die hoffnungsvolle Vermutung, daß die die Produktion zugunsten eines anstehenden Nachfolgers (N150 oder gar einer der N3xx) vielleicht eingestellt haben. Eine Nachfolgeboard mit einer gleichen oder etwas besseren Verteilung der PCIe Lanes wäre schon sehr charmant.

Tja, unter Last und mit so einer Grafikarte ist der Verbrauch natürlich höher. Das ist ja einer der Gründe, warum auch ich der Meinung bin: vielleicht nicht gerade enen leistungsfähigen Gaming-PC zu einem NA Szu machen, weil ein Nas (meistens) ja doch 24/7 oder zumindest oft idle läuft. Ein sparsames NAS im Dauerbetrieb und ein Leistungsfähiges System für die anspruchsvollen Tätigkeiten, der aber nur läuft, wenn man ihn auch braucht. Habe gerade mein Gigabyte B760M DS3H DDR4 mal mit 3TB Nutzkapazität und einer 18TB Disk + 2TB NVMe Cache ausgestattet. Platten Spiundown, system idle, Bildschirmausgang schwarz, 2,5Gb Lan Link, 32GB Ram, I3-12100, 12cm Lüfter für die Festplatten..... knapp über 12W.

Leider ist Dein System (restliche Hardware) unbekannt... Dein aktuelles System mit den externen USB Festplatten schluckt idle (incl. der ext. Festplatten) 15W? Bei einer Nutzkapazität von 3x1TB = ca. 3TB, einer Parity von 2TB und 256GB NVME SSD Cache. Und Du empfindest das als wenig? Hier empfehle ich einen Blick zu der unheimlich lange Diskussion um die N100 Lösung von MPC561. Ich kann es gleich mal suchen, aber selbst mein B760M DS3h DDR4 mit I3-12100 schafft das idle eher zu unterbieten. (Nackt/idle ohne Festplatten unter 10W, schlafende Festplatten dann vielleicht pro Stück knapp unter 1 W)

Eigentlich nicht schwer: Mainboard mit genug SATA Anschlüssen oder ggf. mit einem Zusatzkontroller für SATA Ansschlüsse, CPU und Ram drauf, Netzteil ran, SATA-Festplatten aus den USB-Gehäusen holen und per SATA an Mainboard/SATA-Kontroller anschließen, Stromkabel auch an SATA-Festplatten dran, Ich erkenne anhand der Bezeichnung nicht, was Du da für einen Cache drin hast (SATA oder PCIe/NVME?), aber den sollte man möglichst auch ins System übernehmen. USB Stick in neues Systen stecken, dann von USB unraid starten. Klar meckert unraid, das es das Array nicht korrekt zusammenpuzzeln kann. Alte Array Konfiguration mit "new Config" killen und eben neu zuordnen und dann neu starten. Läuft. Solltest Du (mir unbekannte) Sonderkonstellationen drin haben, mag es an der einen oder anderen Stelle noch Nachbesserungsbedarf geben.

Also SATA Datenträger: Ja, das geht auch. Da sich aber bei diesen Expansion-Festplatten, die aus ihren Gehäusen befreit (geshuckt) werden die Bezeichnungen Ändern wird man danach das Array erneut zusammenpuzzeln müssen. Also schön immer die Seriennummern vor der Aktion aufschreiben, damit man die Festplatten hinterher wieder findet und nicht mit der Parity verwechselt. UD = Unassigned Devices (= einzelne Festplatten ohne eine Raid/Array/Pool Zugehörigkeit).

Was meinst Du damit? Kewin Array, keien Parityät und die Datenfestplatten einzeln nutzen? Ja, das ist sehr einfach möglich: Eben das Array auflösen und die Datenfestplatten eben als UD nutzen. Nur hat man dann keine Ausfallsicherheit mehr.

Korrekt. Und darin eben (vermutlich) einen der beiden enthaltenen Datrenträger. Es wird eben immer gemeldet, daß es da BTRFS Read Errors bei /dev/sdf1 zu geben scheint, welche durch BTRFS korrigiert/ausgebügelt müssen/werden. Ob es nun ein Fehler verursacht durch BTRFS selber ist, oder der Datenträger selber Probleme hat, ist anhand des Logs nicht erkennbar. Da aber die relevanten Smart Werte wohl nicht angestiegen sind, schätze ich, daß es wieder einmal ein rein interner BTRFS Fehler/Problem ist. Man liest hier im Forum ja nicht zum ersten Mal davon, daß sich Probleme ergeben, die sich dann als BTRFS verursacht zeigen. Bei Single Disks bevorzuge ich xfs, bei einem Verbund nutze ich seit unraid 6.12.x da eher zfs. Selbst meine Docker Imagedatei habe ich von btrfs auf xfs umgestellt. Okay, dann hast Du die also alle ins Array verschoben. Dadurch, daß BTRFS (vermutlich als Raid1 betrieben) die Fehler anscheinend erkannt hat, wurden die beim Umkopieren mutmaßlich behoben und Du solltest wohl dann im Array (hoffentlich) fehlerfreie Dateien haben. (Die Hoffnung stirbt zuletzt 😄) Der Paritycheck im array betrachtet nicht den logisch korrekten Inhalt der Dateien, bzw interessiert sich nicht, ob die Dateien darin den gewünschten Inhalt enthalten. Der Paritätschek sichert nur ab, daß die Quersumme aller Bits des selben Sektors (über alle Array Datenträger) dem entspricht, was da ursprünglich als Quersumme berechnet wurde als die Dateien da mal rein geschrieben wurden. Die Samsung 850 Pro ist also Deine SATA Disk im SATA +NVMe BTRFS Raid1 Verbund. Bisher hattest Du ja immer nur von "einer 128GB SSD-Platte und einem 128GB NVM-Speicher" geschrieben. (Ich wußte also nicht welche SSDs Du dort zusammengeschaltet hast.) Wie schon gesagt: ich gehe ja nicht davon aus, daß die SSDs (egal welche der beiden) ein wirkliches Hardwareproblem hat. Der "BTRFS Read Error" könnte im BTRFS System begründet liegen und der "(UDMA) CRC Check Error" in den Smartwerten könnte (mit großer Wahrscheinlichkeit) ein Verkabelungsproblem/SATA Datentransportproblem sein. 2 unterschiedliche Probleme die selber wohl nichts miteinander zu tun haben müssen. Daß somit ein SMART Test eines (oder auch beider) Datenträger technisch keinen Fehler (abgesehen vom hochgelaufenen UDMA Zähler) findet ist somit logisch. Ich wiederhole mich somit: "...und lasse dann Deine BTRFS Datenträger auf Fehler überprüfen und diese beheben." Damit habe ich mich aber wohl unklar ausgedrückt. Sorry!! Ich meine daß Du nicht die SSDs einzeln auf Hardwareproblem prüfen sollst (abgesehen von der Verkabelung der SSD mit den CRC Fehlern), sondern das Dateisystem auf den Datenträgern (BTRFS). Damit war ein Scrubbing oder so gemeint. Da Du aber Deine Daten wohl sowieso alle dort entfernt hast, kannst Du auch einfach den SSD Pool auflösen (new Config) mit den gewünschten neuen Datenträgern neu erstellen, dann den Pool mit dem gewünschten neuen Dateisystem formatieren (vielleicht dieses mal nicht mehr BTRFS?) und dann Deine Dateien wieder vom Array in den Pool zurückschreiben. Ach ja: und dennoch finde ich den Ratschlag richtig, wenn man ein System hat, bei dem vielleicht Daten beschädigt werden können: Backup erstellen! Ergänzungen zu Deinem SMART Protokoll: Deine Samsung SATA SSD ist zwar SATA 3 (6GBit/s) fähig, wurde aber zum Testzeitpunkt aber nur mit SATA-2 (3GBit/s) betrieben. Du hast also Deine (vermutlich) weitaus schnellere NVME SSD nicht nur durch SATA runter gebremst, sondern hast SATA auch noch einmal nur halb so schnell in Betrieb, wie es die SSD hergeben würde. - Benutzt Du ein sehr altes Mainboard, welches nur SATA 2 Anschlüsse hat? - Oder ein altes Intel Sandy Bridge Board, welches 2 unterschiedliche SATA Normen stützt (und Du hast die SSD an den langsameren Port angeschlossen)? - Oder haben die Kontroller wegen den UDMA CRC Fehlern die Geschwindigkeit runter geregelt um weitere Fehler durch 'zu hohe Frequenten' auf dem zu schlechte Kabel zu vermeiden? Das ist leider unbekannt. Siehe Screenshot 1 Du hast auch nicht 99 Fehler im CRC Error Parameter Nummer 199, sondern nur 4. Siehe Screenshot 2 Screenshot 1: Screenshot 2:

Zuerst: Du schriebat anfangs von CRC Error Count. Das ist bei unraid SATA SSD der SMARt Parameter 199. Bei Festplatten heißt der Parameter 199= "UDMA CRC Error Count" Ein UDMA CRC Error Count ist ein erkannter Fehler bei der Datenübertragung zwischen PC Host Kontroller und Festplatten Kontroller. Will sagen von dem einen Kontroller werden Nutzdaten mit CRC Daten zusammen verpackt und zum anderen Kontroller gesendet. Dort werden die Nutzdaten mit den CRC Daten verglichen. Wenn diese nicht korrekt sind wird korrigiert (ggf. durch Neuanforderung). Dabei kommt es NICHT zu Datenverlust, weil falsche Daten erkannt und nicht akzeptiert & weiterverarbeitet werden. Zu Deinem Protokollausschnitt: Also ich lese in Deinem Protokollausschnitt massive BTRFS Lesefehler, die durch Dein BTRFS Konstrukt behoben werden. Das würde mir weitaus mehr Sorgen machen als SMART 199 UDMA CRC Error Meldungen. Mach zuerst mal ein Backup der Daten und lasse dann Deine BTRFS Datenträger auf Fehler überprüfen und diese beheben. Es wäre für Deine Daten fatal, wenn ein Datenträger kaputte Bitwerte hat und Du die SSD mit den korrekten Werten ggf. gegen einen anderen Datenträger tauschst. Dann wäre für die betroffenen Dateien alles "im Eimer".

Im Normalfall deutet das auf Verkabelungsprobleme hin. Bitte prüfe die SATA Anschlüsse/Kabel. Wenn mehrfaches ab- und anstecken (natürlich im ausgeschalteten Zustand) nicht hilft um ggf. Kontaktschwierigkeiten auszuräumen und die UDMA CRC Werte weiter steigen: Faische ggf. das SATA Kabel. Die Verkabelung: ja. Die SATA SSD selber? ist in Ordnung, die brauchst Du nicht zu tauschen. Das kommt ggf. darauf an, wie Du die miteinander verbindest. Ich habe damit keine Erfahrung. aber bei zfs sollen unterschiedliche Größen kombinierbar sein. Natürlich hat man dann aber nur eine eingeschränkte Ausfallsicherheit und somit macht das in meinen Augen nur sehr begrenzten (oder besser kaum einen) Sinn.

Ja, eine iGPU will man, bei unraid und ja, sie kann man ggf. auch für transcoding nutzen (plex). Da Du mit "VM's" eine Mehrzahl angibst (und ich nicht abschätzen kann, was Du darin an Last erzeugst) ist ein N100 vielleicht überfordert. Deshalb würde ich auch zu einem I3 oder I5 raten. ECC Ram und B760 passt nicht zusammen. Ohne ECC: Gute Wahl, der B760 Chipsatz kann energetisch recht sparsam sein. Sobald Last anliegt (VM/Docker) verschlechtert sich das natürlich, ist aber oft immer noch besser als viele andere Chipsätze. Ich glaube Du verwechselst gerne GB mit TB. 😆 Hm.... ich würde mATX oder größer nehmen. Auch da macht sich ein größeres Mainboard & Gehäuse (als ITX) gut, wenn man zukünftig veilleicht erweitern will.

Der Creator erzeugt den Strich um eben für UEFI das Verzeichnis unsichtbar zu machen. Das ist vermutlich eine LIME Entscheidung gewesen um es dem User einfach zu machen. Dann braucht man im Fehlerfalle/beim Problemsuchen nur sagen "mach mal den Strich weg". Es hätte bestimmt mehr Fragen gegeben wenn man den Leuten sagen würde sie sollten das Verzeichnis "Suppenhuhn" oder "Redneck" in "EFI" umbenennen. Bei UEFI muß eben einfach ein EFi Verzeichnis (mit den relevanten Dateien drin) da sein. Aber im Nicht-UEFI Modus (Legacy/CSM) ist es (meines Wissens nach) so, daß es einfach nur kein "EFI" Verzeichnis geben darf.