Pippowicz

Sagen wirs mal so: Ich hab grundlegende Hardware- und auch Netzwerkkenntnisse, das ist aber nicht mein Broterwerb sondern nur ein Hobby. Ich habs mir mal wieder einfacher vorgestellt als es ist. Das mit dem TP-Link probiere ich aus Interesse mal aus, aber wegen Bonding jetzt die Hardware wechseln - eher nicht. Dann lieber ne 10Gbit NIC mit SFP+ Steckplatz und ein DAC Kabel und andere Platten als die WD Reds die bei mir Ärger zu machen scheinen. Ich dachte ich übersehe hier was, einige machen das z.B. mit der Synology und Unifi Hardware - Dort schaut das Netzwerk Setup aber anders aus. Lebenswichtig ist das bisher erstmal nicht. Mal schauen was der Forscherdrang zu Tage fördert. Zukünftig bleib ich bei den Unifi APs, die hier sehr gut funktionieren und beim Switching steig ich bei Defekten auf was anderes um.

Ich habe noch nen Managed TP-Link Switch da, wenn ich später oder Morgen Lust habe probiere ich das mal aus. Wenn ich genervt bin geht die Erfolgsquote eher gegen Null. Daß beim Upgrade auf 6.9.1 was kaputt gegangen ist ist vermutlich eher ausgeschlossen, oder? Deinen Edit habe ich gesehen, das steht auch so in der Unraid Hilfe. Deswegen habe ich das so gelassen. Docker laufen nur Plex und Netdata. Den Rest der Docker Container hab ich auf nem ESXI NUC laufen der immer an ist, der Unraid läuft nur bei Bedarf.

Ich glaube für jetzt ist erstmal die Luft raus, ich probier nachher oder Morgen nochmal. Wenn nicht bleibts halt so wie es jetzt ist oder ich schau mir mgutts Vorschlag an. Danke für Eure Hilfe erstmal

Man kann Profile anlegen die man dann Switch Ports zuweisen kann. Hier ein Screenshot vom Uplink Profil: Die Einstellungen werden dann dem Port (oder der LAG) zugewiesen. Der einzige Unterschied zum Default ist das POE aus ist. Das Profil habe ich selber angelegt daß ich nicht im Default Profil experimentieren muss.

Laut Unifi Doku soll der Switch 802.3ad können. Irgendwie bereue ich dass ich mir vor 4 Jahren die Switches zugelegt habe, die Doku ist nicht besonders gut und die Optionen sind über den ganzen Controller verstreut. Ich wollte das Bonding weil ich zeitweise mehrere Clients mit 1 Gbit auf dem Server habe, die aber selten auf die selben Daten (also unterschiedliche HDDs) zugreifen. Da eine Platte 1 Gbit gut auslasten kann wollte ich das die brachliegende Ethernet Verbindung auf meinem Board im Bond nutzen. Beim Protokoll handelt es sich ausschließlich um SMB Clients. Ich muss zugeben, hier bin ich verloren. Die Unifi Software hat meine beiden Etagenswitches auf "magische Weise" mit Link Aggregation versehen - das musste ich nicht viel machen. Hier noch die Settings im Switch und auf dem Server (Hab zum testen auf Port 19 und 20 umgesteckt): Es handelt sich um die Ports in der 11. Spalte, oben orange (100MBit, unten grün (1 GBit)

Nach meinen Problemen mit meinen Read Errors im Array habe ich eine für mich gangbare Lösung gefunden. Jetzt steht allerdings noch ein "Umbau" an: Bonding der 2 Gigabit Interfaces von meinem Serverboard an meine Unifi Switch. Ich habe dazu schon ein paar Forumsthreads durchwühlt und die Anleitungen befolgt, allerdings erfolglos. Die Netzwerkkarten sind eth0 und eth1, beide werden in den Unraid Netzwerk Settings angezeit. Ich bin folgendermaßen vorgegangen: eth1: Bonding aus, Bridging aus, Network Protocol: IPv4 only, IP Address assignment: None, MTU 1500, Vlans: No eth0: Bonding: Yes, Bonding Mode 802.3ad, Bonding Members: eth0 und eth1, Bridging: Yes, Network Protocol: IPv4 only, Ip Address Assignment: Automatic, DNS: Automatic, MTU: 1500, Vlans: No Dann auch Apply drücken. Netzwerkkabel ist bis zu diesem Zeitpunkt nur eth0 verbunden, Server ist erreichbar. Ein Link wird richtigerweise als down gemeldet. Im Unifi Switch dann die Link Aggregation über Port 13 und 14 eingerichtet, Switch provisionieren lassen. Ab da ist der Server nicht mehr erreichbar. Auch nicht wenn ich das zweite Netzwerkkabel einstecke. Einer der Links wird entweder gar nicht angezeigt oder als 100 MBit. Die Netzwerkkabel sind in Ordnung, auch die Ports am Switch sowie die Netzwerkkarten im Server. Hat jemand eine Idee oder eine Anleitung wie man das richtig macht? Bonding am Switch geht auf jeden Fall, die Switch auf dem Dachboden und im Keller sind korrekt mit einem Bond verbunden.

UUUUUnd ich konnte doch nicht widerstehen und habs eben "schnell" getestet: Wenn die WD Reds im Spindown sind und durch Schreibvorgänge aufs Array geweckt werden kommen in ca. 25% der Fälle die Read Errors, welche HDD von den WD Reds betroffen ist ist völlig zufällig, manchmal sind es sogar mehrere. Ich lass die jetzt halt laufen ohne Spindown und wenn ich ein paar Euros über habe konsolidiere ich meine Daten auf größere Platten - Sinn würde das sowieso machen, aber so ist das halt mir "gewachsenen Systemen" An einen generellen Hardware Fehler kann ich nicht mehr glauben, weil Parity Checks ohne Probleme durchlaufen. Ich denke dieses Mal werde ich Seagates kaufen

Sooo, aktuellstes Bios war drauf, ich hatte allerdings ein Problem mit der Management Engine das mir bisher nicht aufgefallen ist, die war im "Error State" laut Bios. Deswegen war die CPU Temp im Ipmi auch nicht zu sehen. Ich habe das aktuelle Bios nach dieser Anleitung erneut geflashed, nun ist die CPU Temp im IPMI zu sehen. Das LSI Bios und die Firmware ist aktuell, ich hab aber auch hier das OPROM mal aktiviert und reingeschaut, nichts auffälliges bis auf ein paar EInstellungen, später mehr dazu (mit Screenshot).' Den internen LSI Controller kann ich naturgemäß nicht im PCIe Slot umstecken, der muss so bleiben. Das Power Management habe ich im BIOS für ALLE PCIe Geräte ausgestellt - das war an. Powertop nutze ich nicht. Zum Controller BIOS aka Option Rom (lasse ich normalerweise nicht laden weil ich nicht von SAS booten möchte): Hier gibts einstellbare IO Timeouts im Controller BIOS, wirken die auch wenn das OPROM im Mainboard BIOS deaktiviert ist? Ich konnte dazu nichts finden Die Spinup Delays haben mit dem Problem vermutlich eher nichts zu tun, außer vielleicht "IO Device Missing Delay" Ich halte mich eigentlich für recht fit was Hardware angeht, aber das bringt mich echt an meine Grenzen - ich habe eine ganze Weile probiert das BIOS übers IPMI upzudaten, das ging allerdings am Ende gewaltig schief - also BIOS Recovery Procedure. Als das System wieder lief gabs das Problem mit der Intel Management Engine, nach ner Weile Googlen konnte ich auch das lösen. Für Heute ist wieder die Luft raus, Morgen gibts nochmals abschliessend Tests auf dem Array - ich werde berichten

Eine kleine Ergänzug noch: Der Parity Check den ich gestern angestoßen habe läuft nunmehr 12 Stunden ohne Probleme durch, die HDDs sind wieder am Onboard Controller angeschlossen und stecken in der Backplane. Alles in allem echt merkwürdig und vermutlich wirklich Problemen mit dem Aufwecken aus dem Standby geschuldet.

So, nach ein wenig Bastelei Heute hier meine Erkenntnisse: Die beiden WD Reds laufen am Onboard Sata Controller bisher ohne Probleme. Mehrmaliges Standby und Aufwecken durch einen Schreibvorgang bringen die Platten nicht aus der Ruhe. Der Testweise dazugesteckte SAS 2008 zeigt das selbe Verhalten mit und ohne Backplane, die Backplane hak ich also mal als in Ordnung ab. Der Onoard 2308 auch. In diesem Thread redet wer über ähnliche bekannte Probleme mit ZFS, dazu gibts auch eine allerdings 4 Jahre altes Github Issue, ob das allerdings zutreffend ist, keine Ahnung. Es kann sein daß die Platte zu langsam aufwacht und der Treiber schon versucht auf die Platte zu schreiben, diese aber noch nicht Bereit ist. Das würde imho erklären warum Unraid und der Kernel Read Errors melden, das Smart Log aber keine reallocted Sectors (und auch sonst keine Auffälligkeiten zeigt. Mein Workaround wird erstmal sein die WDs nicht mehr schlafen zu legen. Ob es Sinn macht einen Bugreport zu erstellen, keine Ahnung - was meinst Du @mgutt? Ich müsste jetzt lügen, aber mit 6.8.2 gabs dieses Problem bisher nicht und es wäre ein großer Zufall daß nach dem Upgrade all meine WD Reds sterben.

Ich wollte Heute Mittag die Platten umstecken, allerdings ist mir ein Netzteiltechnisches Problem dazwischen gekommen: Es sind keine SATA und auch keine Molex frei, ich brauch erst Adapter - und den Server ins Warme umziehen wäre auch genehmer wenns ans Eingemachte geht. Ich schau mal ob ich Morgen dazu komme - nur daß Du nicht meinst ich lass das jetzt einschlafen. Hast Du schon ne Idee was ich machen kann wenn die Platten an den SATA Ports des Boards laufen? Backplane umbauen, Bugreport (LSI Treiber vielleicht doch problematisch) oder was ganz anderes?

Klaro, sind 6 von 8 frei. Außerdem 4 von 8 SAS Anschlüssen - das sind ja Sata Ports auf dem Board. Ich hab jetzt abgebrochen, alle 3 WDs waren so ca. bei 5Tb gelesen - fehlerfrei. Das mach ich dann aber Morgen gegen Mittag, ich hab Heute keinen Nerv mehr. ich teste dann mit und ohne HDD Standby und der Vollständigkeit halber auch an den 4 freien SAS Anschlüssen. Das Array sollte auch nen Wechsel des SAS Controllers überleben oder? ich hab nämlich noch einen zweiten LSI Controller mit SFF8087 Steckern da den ich bei der Gelegenheit auch mal stecken könnte. Puh, viele Hausaufgaben für Morgen... Irgendwo muss auch noch ein "diskrete" Backplane, also mit 3 SFF Steckern und 1:1 Verbindung auf die HDD Plätze rumfliegen, die hat mir der Verkäufer des Gehäuses damals dazugeschenkt - die müsste ich allerdings suchen, ist *irgendwo* *eingelagert*.

Nach über 2 Stunden dd auf alle 3 WDs bisher Fehlerfrei. Ich lass das jetzt noch weiterlaufen bis Du mich stoppst,

DD "Dödelt" jetzt seit ca. 20 Minuten vor sich hin, bis jetzt null Problemo...

Ich weiß was dd macht, nur die Ideen fehlen mir jetzt so langsam Danke für Deine Hilfe, ich habe Deinen Code mal in drei Screen Sessions gepackt und lass mal alle WDs ins Nirvana kopieren