MAM59

One hint that once saved my life: UPS connection was always lost after some period of time USB port was blocked (needed reboot) What cured this really evil nagging thing (the UPS works flawlessly for ages under Windows, just Linux kills the connection sooner or later) was to insert a small Raspberry-PI USB hub! These have been especially designed (other MIGHT work, but are not guranteed to!) to fix the conflict when devices on both ends supply 5V USB power to the line. In this cases it is not defined which device "wins" and if the other shuts off 5V to that port or not. So there might come up bad situations that create spikes, overload the port or something. The linux driver is very sensitive to this and shuts down the whole port or even controller! (Windows ignores the overload situation and waits some time before it stops the port. In case of a spike nothing happens) So, if you reboot, everything works again, but after some time the loss of connection reappears, give this little (and cheap) hub a chance...

Lucky you are, but you did not get my point. It does not matter which IOT-Net HA is using, it is just, if you collect continous data for statistics (Like I do with my solar collectors) you will always have gaps in the stats because the docker (and VM) is not up all the time and therefor cannot do the timely booking.

better stay with your PI. Its much more stable running HA than any docker or VM can be (HA-OS on Pi also includes more features). Just spend that 5W per hour for your Pi and carry on. (after some painful events I took the opposite tour, started with a docker, moved to a VM and finally ended on a PI. Since then it is fine, no data is missing anymore and updates work fast and reliable too) (And before someone thinks, I want to put down UNRAID, it is just because HA demands some things, nobody can give for sure. For instances it needs to run continuously to pull data out of the devices and create their databases and graphs. This conflicts with any "Os above" that can shut down the Docker / VM without warning (for instance for backup purposes, or, on UNRAID, if the array needs to be taken down to perform some actions). These events will be more or less randon and interrupt long term stats on HA. HA-OS on the PI is prepared for this, it signals backups (does snapshots and so on) and even reloads)

So ganz versteh ich die Frage auch nicht... Du hast also 2 verschiedene Internet Anschlüsse und möchtest, das einige Geräte Leitung 1 benutzen, andere Leitung 2 ? Mit einfachen Routen geht das nicht, da muss man schon etwas mehr Aufwand treiben, aber erstmal abklären, was Du wirklich erreichen willst.

Yeah I know these evil creepy hamsters very well... BTW: what you see at night maybe the general cron job of UNRAID which fires up at 04:40. It is normal that all drives spin up at that time. This may include disk checks and so on... keep that in mind...

too bad, but dont give up yet :-)

Fritzboxen sind doof! Sie speichern nicht wirklich die IP Adresse einer Freigabe, sondern nur die MAC Adresse. Kommen also Pakete von verschiedenen IPs mit derselben MAC bei ihr an, "aktualisiert" sie den Eintrag, so wird aus 168... auf einmal 17... (Geht auch in die andere Richtung, wer zuletzt kommt, gewinnt). Geh mal in die VM Einstellungen und guck nach, welchen Netzwerktyp Du eingestellt hast: BR0 sollte funktionieren, damit kriegt die VM eine IP aus dem Hauptnetz (Deine geliebte 45 :-) ) (und bevor jemand meckert, ja, ich hab hier gar keine VMs :-) ich mags lieber in richtiger Hardware auf einem MiniPC :-) ) Dein wirkliches Problem wird aber darin liegen, dass Du INNERHALB der VM dann nochmals Docker installierst... da hast Du gar keinen Einfluß mehr auf das Netzwerk, weil niemand weis, wie diese Docker eingebunden sind. Das Forum hier kann Dir also nur sehr bedingt helfen... Ansonsten, sollte der Docker direkt in UNRAID sein (also die unnötige VM wegfallen), so muss er im HOST Modus laufen. Damit erhält HA dieselbe Adresse wie UNRAID und es kommen auch Broadcast Meldungen von den Geräten im LAN durch. Nur so kann man in HA diverse Geräte (z.B. Shelly) automatisch finden und einbinden. Ach, noch ein Praxistipp: So, wie Du das da gerne hättest, hatte ich es hier auch mal (aber mit HA direkt in einem Docker, nicht noch ne VM davor). War aber frustrierend, dauernd fehlten Messdaten. Das liegt daran, dass UNRAID oft mal Docker/VMs stoppen muss (Backup, Update usw) und das HA davon keine Kenntnis hat. Da fehlen dann schon häufiger Zeiten in den Kurven und die Auswertungen (z.B. Solaranlage) waren fehlerhaft. Nun ist HA auf einem PI (mit HA-OS) und alles ist gut und vollständig...

start with powertop. it often is the source of evil things...

a "group" can also contain a single disk only :-) so better check the setting. disallow spinup groups globally. But if this has nothing to do with spinup groups, there must be a program that is constantly writing to the drive (therefor the parity also needs to spin up).

Have you created a "spinup group" for a bunch of drives? My experiences so far showed me (nothing official, Limetech does not investigate this so far), that if there is a spinup group, ONE of the drives instantly wakes up again when the others are all down. Deleting the group solved the problem here (but of course now drives wake up again one after the other). This is reproducable. So, if you have such a group, get rid of it for now and watch if the problem goes away or not.

Ach, Alzheimer :-) Verwechselt mit einem anderen Thread wo es um eine 4fach LAN Karte geht, die nicht auf ihre 10G Sollgeschwindigkeit kommt. Ich tanze wohl auf zuvielen Hochzeiten...

Es ist heute fast üblich, dass Motherboards "überbestückt" sind. Da sind dann Komponenten drauf, die man nur alternativ betreiben kann (Im Bios umschaltbar). Deshalb sollte man sich immer vor Kauf das Manual genau angucken und auf (*) (Fußnoten) achten. Bei der Dell Möhre ist wahrscheinlich nicht davon auszugehen, dass der einzige Slot auch noch kastriert ist, aber ein Blick ins Handbuch schadet nie.

Mal so ein Tipp für die Zukunft: Es gibt ein nettes Plugin, mit dem kann man die Plattenzuordnung visualisieren: Wenn eine Platte meckert, ändert sich die Farbe (na ja hier steht die Anzeige auf "Typ" statt "Status". Grün=Pool, Gelb=Array, Rot=Parity. Kann man aber umkonfigurieren auf Grün=ok, Gelb=Warnung, Rot=zu spät) Damit vermeidet man im Zweifelsfalle die falsche Platte rauszurupfen... (man muss aber beim Einrichten einmalig sowohl die Struktur der Einschübe als auch die Zuordnung der Platten manuell eingeben, iss klaaah) Nein, schon richtig. Es ist nur so, dass wenn neue Versionen erscheinen, die alten Pools nicht automatisch hochgerüstet werden. Sonst könnte man nicht später auf die Idee kommen, dass man wieder zurück will zum letzten Unraid. Hat man einmal "zpool upgrade" gemacht, lässt sich der Pool mit der alten Version nicht mehr mounten. Es ist ja auch nur optional, wenn Du die neuen Features nicht brauchst, kannst Du die Warnung auch ignorieren (Die sieht man übrigens, wenn man die Plattendetails aufruft. Da steht dann auch, ob ein Scrub (Reparaturversuch) nötig ist, bzw, ob der letzte automatische Scrub erfolgreich war. Sollte man schon hin und wieder mal reingucken, denn auch wenn ZFS nun in Unraid drin ist, so ganz rund ist das noch nicht. Ein ZFS Problem wird derzeit noch noch nicht automatisch in der GUI angezeigt, die Platte bleibt "grün". Aber, die arbeiten dran, wird wohl bald gehen nehme ich an. Dafür sind die diagnostics gut, da steht die komplette hardware und konfiguration drin. Oft gibt es ja Probleme mit "falscher Slot" oder "dieser Slot darf nicht belegt werden, wenn man SATA 5-8 aktiviert" bei vielen Boards. Da ist es schon wichtig, erstmal nachzugucken, ob auch alles erkannt und geladen wird. Und oft gibt es auch Interferenzen, die der User nicht erkennt und sein Problem eigentlich ganz woanders liegt (Beispiel: "Platte blockiert" wenn in Wirklichkeit das LAN zusammenbricht und neu aufgebaut wird). JaJa, doofe Default Einstellung, meckere ich seit Jahren an :-( Irgendwie ist LimeTech für viele Meldungen unempfindlich.

Aug 29 00:57:35 Tower kernel: ata4.00: ATA-10: ST12000NM0127, G006, max UDMA/133 und [4:0:0:0] disk ATA ST12000NM0127 G006 /dev/sdd /dev/sg3 state=running queue_depth=32 scsi_level=6 type=0 device_blocked=1 timeout=30 Das ist wohl die Platte, die Ärger macht? Ist die einzige, die blockiert ist. Haben wir die falsche ausgetauscht und es klackert immer noch? PS: Du brauchst nicht extra Syslog schicken, das ist bei diagnostics mit drin :-) PPS: Dein ZFS pool ist "veraltet" und bittet um den Befehl "zpool upgrade"... (aber das nur so nebenbei) PPPS: Dein Netzwerk besteht aus einem großen Bond mit allen 4 LAN Karten... Ist wohl immer nur eine angeschlossen? Das ist suboptimal, schmeiss den Bond weg und nehm die "richtige" Karte als eth0 PPPPS: "Intel e1000" ??? aus welchem Museum stammt diese Karte denn? PPPPPS: Du verwendest Powertop. Das kann bei unsachgemässer Anwendung schon mal zu Plattenproblemen führen ("zu viel Strom gespart"). Deinstalliere es besser erstmal. (alle PP... sind optional und habe nix mit dem Plattenproblem zu tun) Da Du da zwei von diesen 12Tb Seagates mit drin hast, hast Du sie wohl verwechselt. Die kaputte ist die, die am internen (Motherboard) Controller angeschlossen ist.

erstmal positiv denken :-) Es scheint ja, dass die defekten Bereiche bislang "datenfrei" sind (zumindest der Anfang). Du könntest also versuchen, einfach die Daten auf eine freie Platte zu kopieren. Eventuell werden einige Dateien angemeckert, wenn sie doch betroffen sind, aber da musst Du durch. Sollte das klappen, kann man dann später Disk1 gefahrlos in den Ruhestand schicken. Ich hoffe Du hast noch genug Platz frei, oder warte auf die neue Platte und halte bis dahin die Füsse still. Wenn Du die Parity tauschen willst, wäre jetzt der richtige Zeitpunkt. Sie ist eh nun ungültig. Du kannst sie aus dem Array rauskonfigurieren und als Datenplatte (muss dann formattiert werden!) neu einbinden. Dann hast Du auch Platz zum Kopieren. Trifft die Neue ein (und ist grösser ??!?) kannst Du sie als Parity neu mit einbinden. Hoffentlich ist der Spuk mit dem Schnarchen beim Aufbau dann vorbei... Also im Prinzip: alte Parity wegkonfigurieren alte Parity als zusätzliche Datenplatte neu mit einbinden Daten umkopieren (zur Sicherheit erstmal NICHT VERSCHIEBEN) Hoffen :-) Später dann: alte Disk1 wegkonfigurieren (eventuell "new config" machen, da ja nun einen Platte zuviel da ist, und immer angemeckert wird) neue Platte einbauen und als Parity konfigurieren Array starten (Parity wird neu erstellt, hoffentlich in ca 30 Stunden)

Nein, das ist nicht seltsam. Die Daten sind auf der Platte verteilt, der Paritycheck geht aber die Platte Sektor für Sektor durch, egal ob belegt oder frei. Somit stösst er zwangsläufig auch auf Bereiche die derzeit noch "frei" sind, aber offensichtlich defekt. Dieses Klackern / Reinitialisieren deutet auf einen Lesefehler hin, im Idealfalle nimmt die Platte dann einen (heilen) Reservesektor und der Betrieb geht erstmal fehlerfrei weiter. Sind die Reservesektoren aber erschöpft (die Liste ist endlich!), dann geht es ans Eingemachte. Da scheint ein ganzer Bereich von Spuren defekt zu sein, das dauert dann Tage um alle Sektoren zu remappen. Es sollten dann aber SMART Fehler für die Platte aufgezeichnet werden, guck in die SMART Liste bzw führe einen intensiven SMART Test durch. Es kann aber auch ein Übertragungfehler der Daten sein. In dem Falle würden die UDMA Fehler hochgezählt... Also, irgendwas ist da und es hat erstmal nix mit dem Controller zu tun bzw. wird durch den Austausch besser. Schick mal endlich diagnostics, so dass man mal einen besseren Eindruck der Kiste kriegen kann. Bislang wirfst Du ja nur Häppchen vor und man kann nur raten...

Der wird das Klackern aber nicht beseitigen befürchte ich... Krieg raus, welche Platte das ist und sichere die Daten solange es noch geht.

Wir hatten doch früher schon mal festgestellt, dass unsere Anforderungen und Erwartungen an Hard- und Software recht diametral auseinandergehen. Also lass gut sein. Dein Kram da ist für mich total uninteressant. Und bei dem hier vorgetragenen Problem (Ich erinnere: "wie repariere ich ein Dateisystem?") auch total irrelevant. Statt rumzumeckern solltest Du vielleicht ihm die Tipps geben, wie er aus dem Schlammassel wieder halbwegs mit Datenerhalt rauskommt.

Recht einfach: dieses ganze "Stromsparzeuchs" ist nicht meins. Deshalb muss ich mich da auch auf die Werbung verlassen. Selber opfere ich lieber ein paar Watt (kommen eh vom Dach) und verwende andere Hardware. Und wenn man schon den Aussagen des Herstellers selber nicht mehr trauen kann, wem dann? Hier gibt es keinen Billigkram wie ASM1166 oder EVO. Update: oops, hab doch ne 960 EVO hier rumfliegen, aber nicht als Datenplatte oder Pool Nur mal so aus Interesse hab ich eben mal UNRAID auf meinem Spiele PC gebootet (AMD 7950X / 5Ghz) und die RAID Funktionen messen lassen Aug 27 08:25:17 Unraid7 kernel: raid6: avx512x4 gen() 43681 MB/s Aug 27 08:25:17 Unraid7 kernel: raid6: avx512x2 gen() 46204 MB/s Aug 27 08:25:17 Unraid7 kernel: raid6: avx512x1 gen() 37259 MB/s Aug 27 08:25:17 Unraid7 kernel: raid6: avx2x4 gen() 44384 MB/s Aug 27 08:25:17 Unraid7 kernel: raid6: avx2x2 gen() 38748 MB/s Aug 27 08:25:17 Unraid7 kernel: raid6: avx2x1 gen() 27723 MB/s Aug 27 08:25:17 Unraid7 kernel: raid6: using algorithm avx512x2 gen() 46204 MB/s Aug 27 08:25:17 Unraid7 kernel: raid6: .... xor() 39780 MB/s, rmw enabled Aug 27 08:25:17 Unraid7 kernel: raid6: using avx512x2 recovery algorithm Das ist doch schon ein deutlicher Unterschied zu den alten Kisten... besonders interessant finde ich, dass selbst ohne spezielle AVX Befehle da fast 40000MB/s bei rauskommen. Das ist fast das 8 fache im Vergleich zur vorigen Generation (der UNRAID Server hier ist ein 5700G)

Ja, DAS klingt nach dauernden Fehlversuchen, Reset und Wiederholung. DIE Platte würde ich mir mal genauer ansehen (Dumm nur, dass inzwischen die Parität kaputt ist, keine Reparatur der Platte möglich, Du musst zum Backup greifen) Mit diesen SATA Controllern kenne ich mich nicht so aus, ich nehm immer nur onboard (8 Stück bei meinem Board) und 4 Port Dinger im Slot. Da ist man auf der sicheren Seite denke ich. Gerade bei den Taiwan-Gülle-Pumpen Dingern weis man ja nie so genau, was man bei der Bestellung bekommt.

AAARG! "ASM1166, a SATA host controller(AHCI) with upstream PCIe Gen3 x2 and downstream six SATA Gen3 ports. It is a low latency, low cost and low power AHCI controller with six SATA ports and cascaded port multipliers" Die mulltipliers ist genau das, was man NICHT haben will. Damit können 2 Platten niemals gleichzeitig funktionieren. Ein Array damit (+Parity) kommt nicht über die Schneckengeschwindigkeit, da bei jedem Zugriff immer vorher der Bus geräumt, der Multiplexer umgeschaltet und der Bus neu belegt werden muß. Kauf lieber Controller mit nur 4 Ports, die haben keine Multiplexer! Ausserdem ist Deine CPU extrem lahm im Umgang mit Array Daten: Aug 26 03:13:23 Tower kernel: raid6: avx2x4 gen() 10098 MB/s Aug 26 03:13:23 Tower kernel: raid6: avx2x2 gen() 9833 MB/s Aug 26 03:13:23 Tower kernel: raid6: avx2x1 gen() 8036 MB/s Aug 26 03:13:23 Tower kernel: raid6: using algorithm avx2x4 gen() 10098 MB/s Aug 26 03:13:23 Tower kernel: raid6: .... xor() 5526 MB/s, rmw enabled Aug 26 03:13:23 Tower kernel: raid6: using avx2x2 recovery algorithm (Mal zum Vergleich mein bescheidenes Dingen: dmesg:[ 0.567606] raid6: avx2x4 gen() 35282 MB/s dmesg:[ 0.584607] raid6: avx2x2 gen() 32229 MB/s dmesg:[ 0.601606] raid6: avx2x1 gen() 24867 MB/s dmesg:[ 0.601611] raid6: using algorithm avx2x4 gen() 35282 MB/s dmesg:[ 0.618608] raid6: .... xor() 5260 MB/s, rmw enabled dmesg:[ 0.618613] raid6: using avx2x2 recovery algorithm ) Deine CPU hat zwar AVX Erweiterungen, aber die sind ihr Geld nicht wert (Ohne AVX 5526MB/s mit AVX bestens 10098... gerade mal doppelt so schnell) Diese Berechnungen werden für Parity benötigt und für jeden Sektor durchgeführt, das Schnarchen summiert sich also auf. Da Deine Parität eh kapput ist, würde ich an Deiner Stelle: Array stoppen 2 (die letzten beiden) Platten auf einen anderen Controller (Motherboard?) umklemmen Paritäts Platte aus dem Array wegkonfigurieren (auf "nicht existent") Array starten Array stoppen Paritäts Platte wieder dem Array hinzufügen (wird nun als "neu" erkannt, es wird also nicht ein Check durchgeführt, sondern eine direkte Neuberechnung) Array starten Die Parität wird somit neu erstellt und wenn Du die richtigen Platten umgeklemmt hast, sollte alles deutlich flotter ablaufen (aber aufgrund der bescheidenen CPU dann doch eher insgesamt träge, nehm Dir für die nächsten 30 Stunden nix Besonderes vor :-) )

hmm, da klemmt aber was gewaltig... Es laufen aber keine SMART Fehler auf? Oder sonst irgendwas Böses im Syslog? Oder läuft da ein heftiger Datentransfer? Steppen die Platten wie wild ? (aka liest/schreibt da was anderes gleichzeitig???)

manchmal merkt man es garnicht, manchmal reichen die Vibrationen der Platten und Lüfter. Checken kostet nix :-) Im Normalen Modus sollte voll reichen. Ich bin mir nicht ganz sicher, ob Du nicht mit dem übereifrigen "xfs_repair" zur Unzeit die Fehler selber produziert hast, aber wenn Du im Maintenance Modus warst, bist Du unschuldig :-)

ok, then sorry for my wish. The modified colors now work in all combinations, that's fine. (I like the "menu bar on the left" thing which is only available in certain themes...)

Hmm, wenn sie nicht meckern, macht es wenig Sinn. Die Zeit (und das Stirnrunzeln) kannst Du Dir sparen. Bau später die Parity neu auf (kein Unterschied zu "Check") und dann sollte Ruhe sein. Kannst ja noch in lost+found gucken, ob die gefundenen Dateien irgendeinen Sinn machen, ansonsten löschen. Und einen bösen Blick auf den Stromanschluß der Platte werfen, nicht, dass da ein Wackelkontakt ist und es bald wieder passiert....