jj1987

Persönliche Meinung und soll kein Angriff sein: 1) Da wird mit ziemlich großen Kanonen auf recht kleine Spatzen geschossen Höchstens die Datenbanken (je nach Verwendungszweck) bräuchten derart viel Power, mit Stromsparen ist da auf jeden Fall nichts. Aber das muss ja auch jeder selbst wissen 2) Ja ZFS geht inzwischen mit Unraid und mit Version 7 auch noch ein wenig besser. Aber es ist mMn nach wie vor NICHT die Kernkompetenz. Wenn man unbedingt ein "Turbo-NAS" bauen will/muss wäre ein TrueNAS vielleicht die bessere Wahl.

Dann mal andersherum gefragt, den Startpost und den Link in den englischen Teil hast du aber gesehen und gelesen? Ist bei mir selbst jetzt schon ne ganze Weile her, aber ich meine da sollte eigentlich alles relevante stehen

Dann solltest du dem eher Mal auf den Grund gehen. Denn wenn auch wirklich die iGPU fürs transcoding genutzt wird, langweilt sich auch ein n100 bei einem einzelnen Stream. Ich vermute, dass bei deiner config irgendwas noch nicht so läuft wie es soll

Löst jetzt nicht das Problem, aber warum führst du das Backup Script nicht direkt auf Server B durch? Also die shares von Server A (meinetwegen auch nur readonly) in Server B mounten und dort dann das Backup Script starten?!

Ja Package =\ cores Nur weil die cores in tiefere c-states gehen, heißt das leider nicht dass das gesamte package das eben auch macht. Denn die zb pcie lanes und noch einige andere Dinge sind ja nicht in den einzelnen cores untergebracht. Ich tippe auf die WD Red SSDs. Als "superduper" NAS/Server SSD gehen die garantiert nicht in Stromsparmodi. Damit bleibt dann der SATA Controller aktiv und das package geht nicht schlafen.

Naja wenn wirklich alle Daten noch unter user0 vorhanden sind, kann ja nichts passieren

Sollte nicht nötig sein bzw im Zweifel sogar alles nur noch schlimmer machen. User und user0 sind ja nur die fuse-Dateisystem Links für das Array inkl Cache (User) bzw ausschließlich Array ohne Cache (user0). Ich würde den Server einfach mal rebooten. Danach sollte alles wieder da sein.

Das wird ziemlich sicher wohl der Grund sein

Kurz und knapp kann man sagen, dass man bei den Kriterien "neu", "ecc" und "günstig" derzeit nur 2 von den dreien gleichzeitig wählen kann. Wenn du auf ecc verzichtest, dann geht neu und günstig. Oder halt eine alte Plattform (Sockel 1151 zb) dann geht ecc und günstig (wobei die Teile inzwischen auch preislich anziehen) etc. So sieht es 2024 leider aus

Ich meine die Disks gehen nicht in spindown, wenn das Array nicht gestartet ist. Oder hat sich hier etwas geändert?

Ist zumindest die 100% sichere, mit Netz und doppelten Boden Lösung. Wenn du allerdings (aktuelle) Backups hast, würde ich mir vielleicht den Zwischenschritt mit der Parity sparen, und einfach die neuen 2x12TB einbauen, new config machen. Von alt nach neu kopieren (wichtig, NICHT verschieben). Dann die alten Disks ausbauen und die neue Parity einbauen und aufbauen lassen. Spart ca einen tag bei (so o.g. Voraussetzung erfüllt sind) überschaubaren Risiko. Zumal du dann ja auch immer noch die Daten auf den alten Disks hättest, falls doch irgendwas schief geht

Erstes No-Go Zweites No-Go Ist nur meine persönliche subjektive Einschätzung, aber da würde ich mich schon nach einer nvme SSD umschauen. Vorzugsweise eine Samsung (Pro), Lexar NM790, Viper Patriot

Also bei UNRAID 6.x verschiebt der mover nur zwischen Array und Cache/Pool. Aber nicht innerhalb des Arrays

Das ist so korrekt, ecc geht ausschließlich mit W680 Chipsatz

Das ist eher eine HDD?!

Aktuell wäre glaube ich 2.15 - warum so eine alte Version?

Wäre jetzt auch mehr als Mittel für die "Erstbetankung" gedacht. Wenn man dann regelmäßig die Backups rüberspielt sollte der jeweilige Upload dann ja schon deutlich kleiner ausfallen

Oder über einen externen Datenträger?!

Das ist so normal. Jetzt wo ein paar Minuten vergangen sind kannst du Powertop (ohne --auto-tune) mal eingeben und dann schauen ob/welche c-states nun erreicht wurden

Da sollte dann powertop helfen. Und wenn du tatsächlich einen 1164 hast, sollte das normal auch keine Probleme bereiten. Beim 1064 hingegen wird von Powertop in der Tat abgeraten

C-States sind "Ruhezustände" Da bei deiner CPU dauerhaft eine gewisse Grundlast anliegt, geht sie nicht in C-States

C-States und CPU Last passen nicht zusammen. Da hilft auch kein powertop. Edit: sorry zu früh auf senden geklickt. Da du bereits powersave als Governor gewählt hast, bliebe nur noch undervolting (kann die Stabilität beeinträchtigen, wäre da also vorsichtig) oder gucken ob man im uefu vielleicht die tdp begrenzen kann. Das kann den gleichen Effekt auf den Stromverbrauch haben aber sollte normal keine negativen Auswirkungen auf die Stabilität haben

Klarer Fall von kommt drauf an. Gibt CPU/Chipsatz/BIOS Kombinationen bei denen mal der CPU Steckplatz, mal der Chipsatz Steckplatz tiefere c-states ermöglicht. Und manchmal geht's bei beiden (oder eben auch bei beiden nicht...).

Also die disk12 könntest du im maintenance Mode mal mit xfs_repair versuchen zu bearbeiten. Wobei bei 512 gemeldeten Fehlern wohl nicht allzu große Hoffnung besteht. Disk3 scheint ja eher ein Verbindungsproblem, auch wenn Kabel tauschen nichts gebracht hat. Läuft die Platte denn sicher an? Kannst du die ggfs an einem anderen PC anschließen?

Läuft powertop auf dem Server? Das deaktiviert USB Ports bei inaktivität. Was dann ggfs den USB Netzwerkadapter deaktiviert, somit wäre UNRAID nicht mehr erreichbar