DataCollector

BTRFS würde ich ab unraid 6.12.x nicht mehr empfehlen. Wenn Du im Pool Raid1 oder Raid0 mit 2 Datenträgern machen willst ist meiner Meinung nach zfs das Mittel der Wahl. Bei Einzeldatenträgern: xfs. Wenn ich im pool keine Ausfallsicherheit (Raid1) nutzen will/muß, bleibt die Frage, reicht Die 2x 1TB oder 1x 2TB. Wenn Du einen riesigen pool für alles nutzen willst zfs Raid0 2x1TB = 2TB Nutzkapazität. Ich würde aber eher alle Systemshares auf eine SSD legen (=Docker, VM...) und die verblein´bende SSD in einem extra Pool für das Cachen der Arraylaufwerke nutzen. Das macht aber auch nru Sinn, wenn Du eben entsprechendes Nutzungsverhalten hast. Sollte das System sich sowieso ziemlich langweilen, und Du auch nie große Datenmengen (bis an die ca. 1TB) von außerhalb auf das Array schreiben, kannst Du die SSDs auch anders aufteilen oder gar eine entfernen und alle sauf einer SSD laufen lassen. Es ist eben sehr individuell. Man kann mit BTRFS (genau wie zfs) auch sowas wie Raid0 machen. Aber da BTRFS doch gelegentlich für lustiges Verhalten/Probleme sorgt würde ich nicht zu btrfs greifen. Das wirst Du uns dann ja mitteilen können. Grundlegend sollte ein B760M Mainboard recht sparsam sein, aber natürlich hängt das eben von den verbauten Komponenten und Firmwares ab. Deine LSi Karte allein wird aber schon die C-States extrem vermiesen. Zumindest gehe ich davon aus, weil ich solches schon mal in meinem B760M vermessen habe: https://forums.unraid.net/topic/156160-gigabyte-b760m-ds3h-ddr4-verschiedene-messungen-werte/?do=findComment&comment=1388195 Bis hierhin brauchst Du also die LSI Karte gar nicht. Da würde ich eher einen ASM1166 einsetzen. Aber das bleibt ja Dir überlassen. Wenn Du einen LSI SAS Kontrolle reinsetzt: achte auf eine gute Belüftung! Fast alle mir bekannten SAS Kontroller von Broadcom (und deren OEM Ableger) werden schnell sehr warm. Den Hinweis auf 200lfm Luftbewegung sollte man sehr ernst nehmen.

Aktuell betreibe ich dieses Konstrukt noch nicht. Ich habe es bisher nur mechanisch zusammengebaut. Ich habe die Lexars 4TB eingebaut, weil ich (als Experiment) eben lieber 4TB SSD verwenden sollte 2 Stück unten, 1 in dem PCIe M.2 Adapter und eine 4TB (aber eine Adata 4TB) am M.2 2230 Anschluß. Dazu eine SATA SSD 4TB. Aber wie gesagt; noch nicht in Betrieb genommen Zu den Lexar SSDs selber: also in meinem B760M Mainbioard waren die überraschenderweise (idle) unproblematisch. siehe Messung 8 in folgendem Beitrag: https://forums.unraid.net/topic/156160-gigabyte-b760m-ds3h-ddr4-verschiedene-messungen-werte/

Mit dem selben Kabel? Nur so ganz nebenbei, weil mich ein fertiges Patchkabel mal einen Nachmittag lang ziemlich die Nerven gekostet hat: Schau Dir das Patchkabel nochmal an. Sind da wirklich 8 oder nur 4 Adern drin (man kann ja durch die meist klarsichtigen RJ45 Stecker schauen). Ich habe mal ein Kabel aus einem neuen Routerkarton genommen und nach ähnlichen Problemen festgestellt, daß die 'Sparbirnen' da ein nur 4 adriges Kabel reingelegt hatten.

Bezogen auf Dein DISK2 Problem: Bevor Du Geld ausgibst: Schließe die Disk2 doch einfach mal Onboard oder einen anderen SAS-Port an. Laut Deiner Diagnostics hast Du: ASUS B85M-E (0MB0F60-M0EAY0) (welches laut www.gh.de folgendes bietet) 4x SATA 6Gb/s 2x SATA 3Gb/s Dazu ein SAS 8 Port HBA Kontroller und daran gemeinsam 10 SATA Festplatten + 1 SATA SSD Also hast Du 14 SATA/SAS Ports, von denen nur 11 belegt sind. Also kannst Du die Disk2 doch einfach mal an einen anderen SATA-Port anschließen um zu sehen ob der Fehler mit der Disk mit wandert (was dann kein Kabelproblem mehr sein kann) oder ob sich keines oder ein anderes Fehlerbild zeigt. Benutzt Du Wechselrahmen/Backplanes oder sind die SATA Kabel direkt auf die Festplatten gesteckt? Und nur so zur Info: diese SAS-SATA Breakout Kabel mit den sehr dünnen Aluschirmen und fast keiner Isolierung sind sehr filigran. Aus eigener Erfahrung kann ich sagen, daß ich mal allein durch ein eher eng verlegtes Kabel anscheinend das Signal des Kabels so verschlechtert habe, daß die daran getestete Festplatte spontan im SMART die CRC Fehler massiv hochgezählt hat. Kabel getauscht: keine neuen Fehler mehr. Wenn man etwas mehr mechanische Stabilität braucht könnt eman sich Kabel mit einer etwas dickeren und somit mechanisch stabileren Isolierung suchen: (Hier nur ein Beispiel, was ich meine) https://geizhals.de/delock-mini-sas-x4-sff-8087-auf-4x-sata-kabel-83057-a428821.html

Wenn Du mit "hinten" die Slots and er Unterseite meinst: Nein. Ich habe dort bei meinem M910x auf je eine Lexar NM790 4TB ein 1mm KUpferstreifen aufgebracht um dann festzustellen, die Bodenplatte geht nicht mehr zu. Ich mußte von der Bodenplatte dann das von innen eingeklebte Gitter abnehmen.

Das war der Hintergrund, warum ich das fragte: https://forums.unraid.net/topic/159009-diks-2-lesefehler-hardware-zu-schwach/?do=findComment&comment=1392437 "Waren die alle an der selben Stelle montiert (gleiche Kabel, gleicher Kontroller, gleiche Backplane?)? Die Geschichte deutet nicht wirklich darauf hin, daß es ein Problem der Disk2 ist, weil Du die ja schon ein paar mal durchgetauscht hast." Primär gehe ich auch von einem Problem im SATA Port, Kabel oder Backplane aus. Aber das danach gemeldete Problem mit dem Bildschirmfoto und dem "Kernel Panik" hat mich eben abgehend vom DISK2 Problem auch zu der Vermutung gebracht, daß dieses neue Problem möglichweise mit dem Ram zusammen hängen könnte. (Schuß ins Blaue)

Das ist eine ganz normale PCIe Karte die durch Bifurcation die Nutzung der x8 Ansbindung des Slot in 2 M.2 PCie Slots verteilt. Dir ist bewußt, daß dafür in dem lenovo M920 herumgelötet werden muß? https://forums.unraid.net/topic/133177-lenovo-m910x-m920x-m90q-als-basis-für-einen-unraid-server/?do=findComment&comment=1270238 und https://github.com/badger707/m920q-pcie-bifurcation/issues/1 sind dabei zu beachten. (Und wenn man der Diskussion dort folgt funktionieren auch nicht alle PCIe M.2 Karten dann in der Lösung.) Das ist keine "Reinstecken und Fertig" Lösung! Im Lieferzustand beherrscht der Lenovo M920 PC kein Bifurcation. Hast Du die Kenntnisse und Fähigkeiten das umzusetzen?

Im Falle der normalen Defaultnutzung: ja. Du willst Reconstruct nutzen. Da laufen dann alle Festplatten bei Schreibvorgängen. ich hege Zweifel and er Einschätzung, daß dies die Festplatten mehr schont als die Defaultnutzung. Korrekt und die Datenfesteplatten werden dadurch nicht schreibend im Maximum betrieben. Ich sehe es anders, da die nicht beschriebenen Festplatten sonst schlafen können und keine extra Starzyklen durchmachen müssen. Aber das ist schon eine sehr alte Diskussion. Startzyklen gegen Laufzeit. Wir sehen es eben unterschiedlich. Mach, was Du willst. Das, was Du vor hast ist meiner absolut persönlichen Meinung nach nicht wirklich das, was eigentlich mit urnaid angedacht war. Aber das ist ja das Schöne: jeder kann es so nutzen, wie es einem gefällt. Und Dein Weg ist für Dich bestimmt der Richtige. Viel Erfolg.

Und welche der beiden steigt immer aus?

Hast Du in dem verwendeten Share so eingerichtet, daß a) ein Minimaler platz frei bleibt und b) bei vollem Cache auf das Array (secondary Storage) durchgeschrieben wird?

Heutzutage macht das zwar eher selten Probleme, aber dennoch kann es eine Ursache sein. Ja. Lass den mal mindestens 24h oder noch länger auf Deinen Ram einhämmern. Auch dabei findet man nicht alle Fehler, aber meist sind dann doch schon Probleme zu finden. Die beiden Memtest86 und memtest86+ sind da eigentlich schon ziemlich gut für geeignet. Da sie beide in ihren testabläufen auch Zufallsmuster testen sind selnbst wiederholende Testdurchläufe nie identisch und somit kan eis sein, daß mal ein ganz seltene sProblem gefunden oder nicht gefunden wird. Auch deshlalb sollte man die schon ziemlich lange laufen lassen, weil die in den Durchläufen immer wieder minimal andere Muster testen. Aber was Du beschreibst deutet ja daraufhin, daß Deine Probleme schon recht füh im normalen betrieb auftauchen. Sollten die RAM dafür verantwortlich sein, sehe ich die Chance als hoch an, daß ein 24h Durchlauf da schon einen vorhandenen Fehler melden wird. Du könntest auch Dein System einfach mal mit so wenig Ram Riegeln (gleicher bauart) laufen lassen und schauen ob der Fehler wieder auftritt. Wenn ich in der Diagnostics richtig gesehen habe sind zumindest zwei baugleiche Hynix/Hyundai HMT41GU6MFR8C-PB drin. Alternative die anderen Beiden ohne diese Hynix verwenden die mit Manufacturer: "0215" zwar nicht wirklich nach namhaften Riegeln klingen, aber auch wohl zusammenpassen sollten.

In einem normalen M.2 NVME/PCIe Slot gibt es keine Kapazitätsbeschränkung in der Hardware. Es ist eine PCIe Schnittstelle und der Kontroller, der dort angeschlossen wirdl (bei einer NVMe SSD auf der SSD integriert) kommuniziert wie jedes andere PCIe Gerät auch mit dem PC. Es gibt uuuuralte PCs, die sowas wie NVMe zum booten nicht kannten und somit im UEFI/BIOS das auch nicht unterstützen. Da kann es sein, daß eine (per Adapterkarte im PCIe Slot) eingebaute NVMe/PCIe SSD zwar erkannt wird aber eben nicht bootet, aber auch da gibt es technisch keine Kapazitätsbeschränkung. Aber diese Systeme haben dann sowieso keine M.2 NVME/PCIe Slots.

Es schon die Festplatten, wenn bei Schreibvorgängen ins Array alle anlaufen und arbeiten müssen, anstatt nur die, die wirklich benötigt werden?

Da Du irgendwie sehr komisch geantwortet hast, kopiere ich die Zeilen von Dir, auf die ich mich beziehe hier manuell ein: Du: "Bisher hatte ich zwei Rechner, möchte das ändern um mein Arbeiten überall im Haus zu ermöglichen, auch Außerhalb." Das geht aber nicht mit nur einem PC, sofern Du den nicht mit Dir herum schleppst. Du: "Mein bisheriger Haupt-PC wird ein Spielerechner für Groß und Klein :). Stromfresser, ja, aber nicht ohne Grund, ich nutze die Leistung ja." Du willst ein NAS mit dauerlaufenden Dockern etc.. aufbauen und der läuft dann vermutlich 24/7 mit dem ganzen Mehrverbrauchsballast der sehr leistungsfähigen Kiste. Diese Konstellation würde aber in den nicht ausgelasteten Zeiten Ressourcenverbrauch haben, den ein externer Rechner im ausgeschalteten Zustand (wenn man eben Geld verdient oder in der Schule ist oder schläft) eben nicht hat. Du: "Das würde mein Vorhaben stark beeinträchtigen. Ich dachte aber, wenn alle Platten gleichzeitig laufen, man keine Einbußen in der Schreibgeschwindigkeit hat." Du zielst auf Reconstruction Write ab. Okay, dann laufen also alle Festplaten des Array gleichzeitig und Du benötigst noch mehr Strom, anstatt die stromsparenden Methoden von unraid zu nutzen und auf den Pools zu werkeln willst Du also zusätzlich ins Array schreiben? Was willst Du denn schreibend mit dem Array machen, daß Du diese Geschwindigkeit brauchst?

Welche SSDs (Hersteller, Type, Größe) werden denn eingesetzt?

Zuerst: Zu Deiner Stromfresserkonfiguration sage ich mal nichts weiter, weil ich mich a) mit den AMD nicht so auskenne und b) die die Anforderungen vielleicht doch besser/sinnvoller in 2 getrennten PC realisieren lassen. Man kann in unraid für die Shares oder auch Pools einstellen, wieviel Free Space bleiben soll. Daß man das für jedes einzelne Laufwerk einstellen kann kenne ich nicht und sehe ich mit Hinblick auf die Fuse-Verwaltung von unraid auch nicht als sinnvoll an. a) Partitionieren: Der Sinn des Array ist alles zusammen anbieten zu können. Man kann Shares auf Disks beschränken, aber Partitionieren? Nicht, daß ich wüßte. b) Ich habe schon viele Benchmarkkurven gesehen, aber linear war keine davon. Eher leicht bogenförmig. Willst Du eine hohe Performance im Array? Ich hoffe Dir ist bewußt, daß die Schreibgeschwindigkeit durch die Parity auf 33-50% der oparity absinkt. Achja, nur so: Du schreibst, daß Du die Parity per zfs verschlüsseln willst. Das ist nicht nur unmöglich, sondern zeigt auch, daß Du Dich bitte noch einmal in die Grundlagen des Array mit Parity in unraid einlesen solltest. Auch sehe ich keinen Grund zfs Verschlüsselung im Array zu nutzen, wenn die xfs Verschlüsselung auch gut funktioniert. Sowas ist mir nicht bekannt und würde in die Dateisystemverwaltung eingreifen. In eine bestimmten Share: ja, das ist Möglich. Du legst einen Share en aund schreibst die Dateien da rein. Aber urnaid entscheidet selber, auf welchen Sektoren die auf den Datenträgern liegen.

Da die Parity signifikant die Performance des Array beeinflußt tendiere ich dazu zu empfehlen die Parityfestplatte sollte immer die flotteste von allen sein (sofern die Größe paßt). SMR ist dabei eben eher schlecht. Besser macht man da einen Bogen um SMR. 7200RPM Platten sind eigentlich immer schneller als 5400 oder 5900 RPM Platten. Die Datenfestplatten hingegen werden ja schreibend weniger belastet so (da sie per Defaulteinstellung durch die Parity ausgebremst werden), daß ich dort auch SMR als akzeptabel ansehe (gibt aber Leute mit dahingehend anderer Meinungen). Wenn man die Wahl hat, sind (meiner persönlichen Meinung nach) zwar auch da CMR und 7200 Rpm zu bevorzugen, aber das ist ja der Vorteil von unraid, das ist bei den Datenfestplatten nicht wirklich pingelig. Einige Leute bevorzugen dennoch 5400 oder 5900 RPM Platten, weil diese bei den Leuten wohl leiser laufen. Das ist also eine persönliche Entscheidung. Im Wohn- oder Schlafzimmer wäre ich auch sehr auf die Lautstärke ausgerichtet, aber meine System sind in einem abgeschotteten Raum und da stört mich die Geräuschkulisse eher weniger. Waren die alle an der selben Stelle montiert (gleiche Kabel, gleicher Kontroller, gleiche Backplane?)? Die Geschichte deutet nicht wirklich darauf hin, daß es ein Problem der Disk2 ist, weil Du die ja schon ein paar mal durchgetauscht hast. Du kannst ja mal versuchen das Netzteil zu tauschen, aber ich fahre in meinem kleineren System 7Daten+1Paritydisk an einem Corsair RM550x und das ist aktuell für bis zu 15 Festplatten ausgelegt (+ Wechselrahmen mit Extralüftern, mehrere SSD etc...). Mit den 8 Disks die gleichzeitig starten, schluckt das System rund 145W. Wenn ich Deine Diagnostics richtig durchgezählt habe, hast Du 10 Festplatten + 500GB SATA SSD und den Bootstick dran. Ich glaube nicht, daß ein Paritycheck Deines oder auch meines Systemes wirklich die Grenzen eines 550W Netzteiles ausreizen würde (sofern das Netzteil nicht defekt ist). Das man das Syslog auf den USB Stick schreiben kann ist Dir bekannt? Für Diagnosezwecke ist das gut. Sollte man aber nicht unnötig laufen lassen, da es den Flashstick beschreibt udn der nur endliche Schreibzyklen durchsteht. Was das Bildschirmfoto angeht: Meine Kenntnisse sind zu schwach, als daß ich das analysieren könnte. Aber nur so als Idee, wenn ich die Kernel-Panik meldung lese: Hast Du schon mal den Arbeitsspeicher (RAM) intensiv getestet? Da auch bei der Paritygeschichte immer viel Ram im Spiel ist könnte ein defekter Speicher vielleicht eine Ursache all Deiner Probleme sein?

Es gibt zwar auch Exos mit SAS, aber eben auch SATA. Aber Du hast recht, sollte @Timmey85 SAS Festplatten einsetzen, ist der SAS Kontroller zwingend erforderlich.

Wenn es der Strom wäre, würde ich mir vorstellen, daß die Fehler wandern oder ist diese Disk2 eine besonders stromfressende Festplatte? Nur so zum Testen würde ich die Festplatte mal anders anschließen. Ein anderer Port des Kontrollers oder gar an das Mainboard hängen und beobachten ob der Fehler bei der Disk2 bleibt oder ob dann andere Festplatten diese Probleme haben, die an Position der ehemaligen Disk2 angeschlossen sind. Auffällig: Disk2 ist eine Seagate SkyHawk +Rescue 4TB, SATA CMR 5900Rpm 6Gb/s (ST4000VX016) Die haben für DVB Unterstützung ja eine spezielle Firmware, die bei Engpässen (eigentlich für Videostreams) auch Bits verwerfen darf. Könnte es damit zusammen hängen? Nebenbemerkung: Du verwendest eine lustige Mischung aus CMR und SMR Festplatten verschiedenster Drehzahlen in Deinem System. Wobei mich am meisten irritiert, daß Du eine SMR als Parity einsetzt. Aber wenn es bisher geklappt hat und Dich weiter nicht stört... Wenn Dein array viel schreibt, bricht durch SMR die Schreibrate nach einiger Zeit stark ein, weshalb die Parity möglichst keine SMR sein sollte. Aber ich glaube nicht, daß dies etwas mit dem aktuellen Problem zu tun hat.

Das klingt nach verbogenen oder ausgeleierten Kontaktdrähten in der Buchse. Man kann diese versuchen nachzubiegen, das ist aber filigrane Arbeit und wenn es schief geht ist die Kontaktgabe in der Buchse ganz hinüber.

Du erinerrst falsch. Da Quelle und Ziel unerschiedliche große "SMB-Freigaben" sind (oder Windowslaufwerke) ist eien automatisierte synchronisierung/abgleich(/bAckup bei mir nicht so einfach möglich. Ich nehme den Totalcommander und lasse so die Verzeichnisse innerhalb der SMB Freigaben angleichen.

Dann kann man aber immer noch hinter diesen "Zwangsrouter" einen eigenen Router stellen, der dann das VPN übernimmt. Das wäre zumindest meine Idee. Ich bin kein Freund davon solche sicherheitskritischen Sachen virtuell in dem System selber zu realisieren, weil dann ggf. eine einzige Hürde zu überwinden ist um Zugriff zu bekommen. Mit einem VPN fähigen Router dazwischen wären es schon einmal 2 unterschiedliche Hürden. Tja, wenn es im lokalen LAN wäre würde ich FTP empfehlen. Wenn Du 2 Netzte (entfernt und lokal) per VPN koppelst, wäre es (je nach Fähigkeit der VPN Verbindung) so, als wäre es ein großes Netz und dann wäre darin auch sicher FTP machbar. Ich sehe eigentlich keinen Sinn ein Nas in ein NAS zu installieren. ja, es gibt Leute, die das machen, aber dann ghen viele der Vorteile von unraid 'flöten'. Ich würde es zumindest probieren. Es muß auch nicht zwingend eine FB sein. Verschiedene andere Hersteller haben ja auch VPN Verbindungsmöglichkeiten drin. Nebenbei: sollte einer der Standorte keien direkte IP Adresse nach außen haben wird es noch mal eine Stufe schwieriger, aber das ist nicht mein Fachgebiet. ich mag es, wie einfach es die Fritzboxen mir machen und ich habe eine IPv4 die von Außen direkt zu erreichen ist.

das 1st System Tessa (siehe Signatur) mit seinen rund 400TB war erst mal mein 2. Backup (weil ich das System noch imme rnoch nicht so zusammengepuzzelt habe, daß es mein Hauptsystem (bisher Windows basiert) ersetzen kann. Meine Primärsysteme sind 2 andere PC (Windows basiert), die ich per 10GBLan sporadisch synchonisiere.

Eine SSD behält ihre Daten, sofern sie nicht gerade mitten im Schreibvorgang absolut ungünstig abgewürgt wird. Die Daten eines RamCache sind von einem Stromausfall betroffen. Da unraid aber per Default alle (ich glaube 20 Sekunden) den RamCache an seinen Zielort befördert sind diese Cachedaten nur solange gefährdet, wie es dauert die wegzuschreiben (mehr Ram = mehr wegzuschreiben). USV ist sinnvoll, aber es wäre jetzt schon ein ziemlicher Unglücksfall, wenn nun in den ersten Tagen des unraidaufbaus ein Stromausfall zuschlägt. Und Da Du angedeutet hast, dass Du ziemlich neu bist: Du willst ja Dein System aufbauen und das Array dann ja mit Deinen Daten füllen: Wenn Du am Anfang keine Parity (also keine Ausfallsicherheit) einstellst, schreibt es sich bei der ersten Befüllung schneller auf das Array. Wenn alles da ist, wo es hin soll, kannst Du die Parity später (in ca. 1,5 Tagen) nachträglich erstellen lassen. Beachte: keine Parity, keine Ausfallsicherheit des Array. Aber Dein Kumpel hat ja ein Backup.

Man könnte es so einstellen, daß die Systemshares auf dem Array liegen, aber das macht keinen wirklichen Sinn, weikl das Array erheblich langsamer schreibt als ein Pool mit einer SSD. Hier zeigt sich, da0 Du noch eine gewisse Lernkurve hast. Der Cache muß kein SATA sein und der Cache ist auch nicht "im" Array. Der wird als Pool dem Array vorgeschaltet. Ich weiß nicht wie wichtig Dir die Daten in den Caches ist, aber ich würde anstreben: 1. NVMe SSD (ohne Ausfallschutz, also kein Raid) für die Systemshares zu nutzen, da Du anscheinend ja viel mit Docker+VM arbeiten willst. 2. NVMe SSD (ebenfalls ohne Ausfallschutz) als Cache für das Array zu nutzen. Deine SATA SSD kannst Du entweder für Daten im Array benutzen, oder als weiteren Cache für andere Sachen oder aus dem System entfernen. Da ich nicht weiß, wie groß die jeweiligen SSD sind, ist dies nur ein Denkanstoß. Ein winziger Cache für das Array macht beispielsweise kaum einen Sinn. Ja. Ich kenne zwar den 9305 nicht, aber meine 9300 sind echte HBA und somit sind sie dahingehend problemlos. Gut, daß Du ein Backup bedacht hast. Denn ich weiß selber aus schmerzlicher Erfahrung: Ein Raid und auch ein unraid können zwar den Ausfall einzelner Datenträger verkraften, aber wenn etwas gravierendes passiert sind die Daten sonst futsch. Da macht sich dann ein Backuo gut. Zu SFTP kann ich nichts sagen, da ich es nicht einsetze.