jj1987

Ich weiß leider nicht mehr ob hier oder in einem anderem Forum, auf jeden Fall wurde genau dieses Thema shcon mal durchgesprochen. Dabei wurde dann auf diesen Blog hingewiesen. Das hab ich ich grob schonmal durchgespielt, nur noch nicht jeden PWM-Controller duchgetestet. Das vorgehen sollte also so korrekt sein. Fand ich aber irgendwie zu Kommandozeilenlastig oder schlich nicht elegant Jetzt bin ich darauf gestoßen, dass wenn man sich die Plugins "Dynamix Auto Fan Control" und "Dynamix System Temperature" installiert, die sich sehr gut ergänzen und man über letzeres Plugin zumindest schonmal den Treiber für die PWM Controller eingebunden bekommt. Dann braucht man nur noch die einzelnen Controller duchprobieren, welcher nun der richtige ist für den gewünschten Lüfter. Und das ist der Punkt an dem ich aktuell mangels Zeit noch nicht weiter gekommen bin.

Stimmt im Go-file werden ja nur "normale" Befehle ausgeführt. Da könnte man das "echo..." einsetzen. Das clocksource=hpet ist ne Kernelbedingung. Müsste dann in die Syslinux. Ich empfehle zu testzwecken einen zusätzlichen Eintrag einzufügen

Wie man das auslesen könnte weiß ich leider auch nicht. Falls du dir sicher bis, noch nie ein Firmwareupdate gemacht zu haben, ist auf der SSD auf dem Typenschildaufkleber die Firmwareversion aufgedruckt. Und was das Update angeht, laut News-Update soll das ja seit Ende Dezember funktionieren?! Edit: Habe da gerade was bei Google gesehen, dass das wohl per smartctl ausgespuckt wird (device logischerweise anpassen): smartctl --all /dev/sda Als Ausgabe sollte dann kommen: === START OF INFORMATION SECTION === Device Model: CT250MX500SSD1 Serial Number: xxxxxxxxxxxxxxx LU WWN Device Id: xxxxxxxxxxxxxxxxx Firmware Version: M3CR020 ...

Besteht der Fehler auch mit der neuesten Firmware (M3CR033) noch? Hatte mir jetzt 3x 1TB MX500 im Angebot zugelegt, die ich noch als als zusätzlichen Cache-Pool im RAID5 verwursten will. Und so ne Fehlermeldung würde mich schon irgendwie nerven..

Ok ich muss meine vorherige Aussage präzisieren. Die CPU wird selbst ohne Anpassung der Gehäuselüfter beim z.B. Parity-Check nicht auf kritische Temperaturen kommen bzw regelt der CPU-Lüfter da dann entsprechend gegen. Eine Regelung müsste also schon bei verhältnismäßig niedrigen CPU-Temperaturen ansetzen und wird eben durch den eigenständig agieren CPU-Lüfter erschwert. Zielgenauer ist daher schon die Steuerung per HDD-Temp. Dafür nur leider etwas umständlich umsetzbar. Und klar, wenn der Server irgendwo in der Besenkammer/Serverraum/Technikkammer steht und niemanden stört dann kann man natürlich auch das Signal auf 100% festnageln und brauch sich keine weiteren Gedanken machen

Meinst du mit mbps eigentlich mBIT oder mBYTE? Falls mBYTE wird da nicht viel mehr gehen. Bei GBIT LAN ist das so ziemlich das Maximum.

Naja die CPU wird aber ja nicht unbedingt wärmer, wenn's die HDDs werden und andersherum. Deshalb will ich meinen unteren Front-Lüfter der direkt vor dem HDD-Käfig sitzt auch noch dazu bewegen auf die HDD-Temps zu reagieren. Technisch möglich ist das über die Kombination mehrerer Plugins. Und dann muss man halt noch zum richtigen Lüfter den richtigen Controller zuordnen. Dafür muss man dann aber am besten neben dem Unraid Server sitzen und jeden Controller einmal auf 100% setzen um zu hören/sehen ob man nun den richtigen erwischt hat.

Mal so ins Blaue zum temporären Test (wird einen reboot ja nicht überleben), auf der Kommandozeile mal eingeben: echo "hpet" > /sys/devices/system/clocksource/clocksource0/current_clocksource Wenn das dann tatsächlich hilft müsste man dann vermutlich im Go-File folgendes eintragen: clocksource=hpet

Spontan sieht mir das eher so aus, als ob das Netzwerk da limitiert. Hast du mal eine externe HDD an den Unraid Server geschlossen und dann direkt etwas von extern auf das Array kopiert? Das zweite Problem ist etwas komplexer, dadran arbeite ich auch gerade. Ist aber, nach dem was ich so gefunden aber, mit viel ausprobieren verbunden da man die PWM-Controller manuell auswählen muss (und somit auch die "richtigen" erwischen muss).

@mgutt, @hawihoney, @psychofaktory: Habt ihr im BIOS einen Punkt "HPET" und wenn ja ist der aktiviert oder deaktiviert? Das ist ein (neuer?) Timer der aber wohl häufig Standardmäßig deaktiviert ist.

Das wird sehr wahrscheinlich nicht funktionieren, zumindest hat es soweit ich das verfolgt habe noch niemand erfolgreich geschafft. Hatte es selber auch mal vergeblich versucht. Da sind die AMDs (noch?) etwas zickiger als die Intels.

Nicht ganz, die Xeon-W sind die Nachfolger der Xeon-E. "Richtige" Server Xeons sind die Bronze/Silver/Gold/(Platinum) die kosten dann aber auch so richtig Asche (vorallem dann auch mit der entsprechenden Infrastruktur). Beide Generationen (Xeon E/Xeon W) sind, so wie alles eigentlich momentan, nur schwierig zu erhalten, daher auch tendenziell höhre Preise als "üblich". Es gibt hier ein paar die schon die Xeon-Ws im Einsatz haben, das eigentlich empfohlene GIGABYTE W480M Vision W scheint aktuell aber noch ein paar Macken zu haben. Falls du die "alte Garde" sonst nehmen willst (leistungsmäßig hat sich ja nunmal bei Intel die letzten Jahre sowieso nicht soviel getan), wird ebenfalls Gigabyte empfohlen, konkret entweder das GIGABYTE C246N-WU2 oder das GIGABYTE C246M-WU4. Diese Empfehlungen basieren in erster Linie auf einem niedrigen Idle-Verbrauch (da wenig und/oder abschaltbare Komponenten verbaut sind) und einer doch recht guten Ausstattung. Keines der Boards hat allerdings IPMI. Da wäre wohl ein Supermicro-Board tatsächlich die erste Wahl. ECC funktioniert relativ sicher mit AMD, einzelne Boards unterstützen das nicht, das genannte AsRock allerdings schon. Idle-Verbrauch ist in der Tat etwas höher als bei Intel (im Grundausbau!), mit einer X540 die dann ja auch genutzt werden will sind die Idle-Verbräuche aber ja sowieso schon nicht mehr bei den im untersten Fall 10W die man mit Intel schaffen kann. @Smolo hat z.B. das AsRock Board und kommt mit einem 5600X auf ca. 35W im Idle (inkl 10G Karte und dGPU). Alternativ könntest du, so wie ich es mache, einen Ryzen Pro 4000 nehmen, der hat dann auch ein iGPU. ABER: die wird noch nicht so gut unterstützt. Da käme es auf deinen konkreten Use-Case drauf an. Da ist zugegebenermaßen Intel (noch) im Vorteil.

Bestimmt alles Eigenbedarf, wird jetzt ne Chia-Farm😜

Rückblickend muss ich auch feststellen, tatsächlich Mal den richtigen Zeitpunkt erwischt zu haben. Das eigentliche System hab ich mir kurz vor Weihnachten zusammengestellt, da war RAM auf Tiefstkurs (inzwischen ärgere ich mich nur 2x16GB genommen zu haben, obwohl ddas wenn ich ehrlich bin auch dicke reicht 😉). Festplatten hatte ich über's das Jahr verteilt immer wieder im Angebot gekauft. Und dann um Ostern rum nochmal 2x 16TB Platten nachgeordert. Die eine liegt noch original verpackt rum. Kann mich noch nicht entscheiden ob ich die einbaue oder als Backup nutze...

Ich würde mal sagen, da bist du ungefähr zwei Wochen zu spät dran. Da kann man jetzt nur hoffen, dass der Chia-Hype schnell implodiert. Selbst HDDs unter 6TB sind schon deutlich im Preis gestiegen

Theoretisch kannst du Windows auch ohne Lizenz nutzen, dann kommt zwar bei jedem Start die Aufforderung "Bitte aktivieren" und du kannst den Hintergrund und ein paar andere Dinge nicht verändern, aber gerade zum testen ist das ja nicht weiter wild.

Also nachdem bei Geizhals.de plötzlich statt nur Amazon.uk mit unbestimmter Lieferzeit nun insgesamt 6 Shops das C246N-WU2 anbieten, orakel ich mal dass die Boards demnächst bei deinem Großhändler lieferbar sind

Hast du denn den iGPU-Treiber in Unraid installiert/geladen? Das Problem hatte ich nämlich anfangs mit meinem Ryzen auch. Erst nachdem die Treiber installiert waren, funktionierte auch der GUI-Modus (ich Nachhinein ja auch irgendwo logisch)

Kannst du im BIOS auswählen welches die primäre GPU ist? Falls nicht bleibt dir wohl nur die Steckplätze der GPUs zu tauschen

Ich meine das bezieht sich nur auf defekte HDDs. Je Paritätsplatte kann eine Datenplatte ausfallen. Jetzt willst du aber ja ein intaktes Array erst verkleinern und nach reboot mit neuen/anderen Platten vergrößern. Das sollte mMn keine Probleme geben solange du an der Zuordnung der Paritätsplatte(n) nichts änderst

Wenn die sowieso leer sind, würde ich wie folgt vorgehen: 1. Array stoppen 2. Festplatten in Unraid aus dem Array entfernen 3. Array wieder starten 4. Unraid runterfahren 5. alte Festplatten ausbauen, neue einbauen 6. Unraid starten 7. Array wieder stoppen 8. Neue Festplatten in Unraid dem Array hinzufügen 9. Array starten Ich bin mir nicht ganz sicher ob vielleicht bei 3. doch ein Parity-Check/Rebuild gemacht wird. Aber das dürfte generell die beste Vorgehensweise sein.

Du könntest auch BTRFS nehmen, da gibt es inzwischen einen Windows Treiber: https://github.com/maharmstone/btrfs

Ist glaube ich auch ein Denkfehler von mir gewesen. Zum verschieben (Von Cache auf HDD) muss der cache auf "Yes" stehen. Bei No läuft der mover gar nicht. Nach dem verschieben vielleicht sicherheitshalber dann Cache auf "No" damit während der Aktion nicht doch irgendwas versehentlich wieder auf dem Cache landet

Am einfachsten wäre es wohl für alle shares temporär den Cache auf "no" zu setzen, Docker-Service(!), VM, etc kurz deaktivieren, mover starten. Wenn fertig den Cache für die shares wieder aktivieren und entsprechend die Pools zuweisen. Wieder mover starten. Docker-Service VMs wieder aktivieren

Naja er schreibt ja dass der Share "Filme" im Container gemountet ist. Wenn jetzt dieser Share womöglich auch noch über mehrere HDDs verteilt ist, kann das natürlich der Auslöser sein. Analog der Bibliothek Aktualisierung von Plex, Emby etc.