jj1987

Das ist das Fuse Dateisystem, also die Summe aller Array Disks plus ggfs Cache

Waren B560 nicht einfach nur umgelabelte B460?

Bei "bevorzugt" bleibt auch alles auf der SSD. Mit dem "Vorteil" dass, wenn auf der SSD der Platz ausgeht dann auf der HDD weiter geschrieben wird. Bei "nur" würde die SSD randvoll geschrieben und dann einen Fehler ausspucken. Wenn du dir also zu 100% sicher bist, dass du die SSD nie (und sei es nur aus Versehen) vollschreibst spricht nichts gegen "nur"

Wobei du ja immer noch keine iGPU hast🤔 Aber vielleicht kann man auch die Nvidia in den Container einbinden?! Weiß aber nicht ob das nennenswert Strom spart

Naja, das ist ja das Docker System, da können grundsätzlich nochmal komplett andere User Rechte gelten. Ist ja ne kleine VM (ist es ganz genau betrachtet nicht, aber zur Veranschaulichung trotzdem treffend)

Also ne kurze Google Suche vermittelt mir den Eindruck das Quicksync grundsätzlich unterstützt wird. Desweiteren gibt es von OBS wohl auch Docker Versionen. Das wäre unter dem Aspekt stromsparen natürlich auch ein guter Ansatzpunkt. Inwiefern die Docker Versionen dann wiederum Quicksync unterstützen (das ist leider eine individuelle Geschichte, je nachdem wie die Docker erstellt wurden) müsste man dann ausprobieren.

Ich muss gestehen ich kenne OBS nicht im Detail, daher auch der Verweis dass Intel Quicksync unterstützt werden müsste. Aaber wenn das gegeben ist und du wirklich nur den Stream damit verarbeitest/transcodest sollte die IGPU (auch per gvt-g) nur müde lächeln

Sowohl unter Last als auch idle könnte man ggfs noch etwas Strom sparen wenn man das auf 2x 16TB (oder größer) konsolidiert Schonmal keine gute Voraussetzung fürs stromsparen. Benötigst du die Redundanz? Sonst Mal ausbauen, sofern der Server dann nicht meckert

Da er einen "F" Prozessor hat, gibt es keine iGPU. Für seinen Einsatzzweck mMn daher eigentlich die falsche CPU. Ansonsten wäre das mit gvt-g und ggfs Intel QSV (sofern vom Programm unterstützt) schon ne saubere Lösung

Korrekt, gilt nur für neue Daten Die einfachste (da "klickibunti") wäre dann "unbalance" aus den Community Apps. Da kannst du einzelne (Unter-)Ordner von einer Festplatte auf die andere transferieren

Im dümmsten Fall musst du tatsächlich ASPM für die SSD abschalten. Es scheint je nach Kombi aus Mainboard/SSD/Betriebssystem ein hartnäckigeres Problem zu sein

Der part ist ein Fehler im Stromsparmodus deiner eingesetzten NVME (ich vermute Mal eine Western Digital?) Das hatten wir hier schon: https://forums.unraid.net/topic/121146-nvme-aer-corrected-error-und-pcie-bus-error/?do=findComment&comment=1108543

Oh, dachte das wäre schon länger her...

Auf welcher Version bist du denn? Das ist seit Version 6.11. (oder sogar irgendeine 6.10.x?) behoben

Schon kurios, ich hatte (aus Geiz) seinerzeit auf die günstigeren, und langsameren, SN550 gesetzt. Die machen bei mir überhaupt keine Probleme. Das günstiger auch Mal Vorteile hat, hätte ich auch nicht gedacht...

Mhm nö. Alle haben DRAM Cache, die 870 EVO ist immer TLC, die 870 QVO immer QLC und die Sandisk SSD kann beides sein.

Ich nehme an du hast nur ein einzelnes Cache Drive? Bei den beiden genannten shares ist die Cache-Nutzung aktiviert. Alle Daten die im Cache liegen sind NICHT durch die Parity geschützt. Wenn also das Cache Drive ausfällt sind die Daten verloren. Deshalb (wenn nur ein Cache Drive möglich/ gewünscht) ein passendes Backup Konzept überlegen und die Warnung guten Gewissens ignorieren oder halt ein zweites Cache Drive hinzufügen sodass ein RAID1 entsteht und dadurch ein gewisser Ausfallschutz sichergestellt ist. ABER auch hier gilt: "RAID ersetzt kein Backup" und "kein Backup - kein Mitleid"

Gerade bei sata SSD ist ein DRAM Cache Pflicht, da solltest du also auf jeden Fall drauf achten. Ansonsten die 870 EVO wäre der "Mercedes", @mgutthat aber meine ich auch schon die 870 qvo getestet und für brauchbar befunden und als reine Datenablage sollte QLC jetzt auch nicht so tragisch sein. Etwas günstiger wäre noch die Sandisk SSD Plus, dafür dann nicht so performant

Vorallem Bei Single Thread Prozessen dürfte die Limitierung eh nicht zu spüren sein (solange es dann auch nur ein einzelner bzw einige wenige sind) denn ein einzelner Kern wird kaum die 65w ausschöpfen. Bei den Ryzen hatte man im CB Forum mal meine ich 20-25w für einen einzelnen Kern als Maximum ausgemessen. Denke das wird bei Intel nicht viel anders sein. Sprich bei einer Limitierung auf 65W sollten zwei Kerne volle Pulle ackern können ohne ausgebremst zu werden (Turbo weitestgehend sogar inklusive). Das sollte für die allermeisten Szenarien dicke reichen

Jein, wenn (wie es bei Intel seit gen10/11 leider der Fall ist) überproportional viel Strom aufgewendet werden muss um die Mehrleistung zu erreichen. Brechstange ist da dann wieder kontraproduktiv. Solange der Stromverbrauch halbwegs mit der daraus resultierenden Mehrleistung proportional skaliert stimmt deine Aussage aber

Ja war auch mehr als Ergänzung zu meiner ersten Aussage bzw zur Rückfrage von @UnKwicks gedacht

Bei 12.+13. Gen dann ab i5-1x500(?) meine ich

Dann geht aber kein ECC und du könntest auch irgendein z690 Board oä nehmen

Der Punkt ist leider der, dass es bei aktuellen Boards den Anschein macht, dass es schlicht keine sparsamen mehr gibt. Zumindest wenn sie dann auch noch mehr als 6x SATA haben sollen und womöglich sogar noch ECC unterstützen sollen.

Ist bei den "Tunables" ein Punkt. Vielleicht interpretiere ich zuviel in die Frage hinein, aber nutzt du das S3 Sleep Plugin? Dort in den Einstellungen kannst du Befehle die vor Sleep ausgeführt werden sollen eintragen. Dort müsste dann entsprechend der Befehl eingetragen werden (falls mehrere NICs vorhanden sind ggfs das Interface noch anpassen): ethtool -s eth0 wol g