jj1987

Dann nimmst du 3x10TB + 3x4TB als Datendisks und die eine übrig bleibende 10TB als Parity. Verstehe da ehrlich gesagt die Frage nicht so Recht?! Jup, ganz einfach ausgedrückt: pro Parity Disk darf jeweils eine Datendisk kaputt gehen. Ob eine zweite Paritydisk bei 6 Datendisks "erforderlich" ist kannst schlussendlich nur du selbst beantworten. Bedenke aber auch, selbst wenn eine Disk "zuviel" kaputt geht, verlierst du ja Dank der Funktionsweise des Array nur die Daten auf der jeweiligen Disk. Alles anderen Platten haben ja ihre vollständigen Daten noch

Dateisystem ist da irrelevant. Das liegt an der Funktionsweise des Array bzw der Parity.

Kurios, der Adapter ist ja eigentlich ein passives Element (dachte ich zumindest bisher). Dass der das dann beeinflusst 🤯

Alturismo hat im Prinzip schon alles gesagt, aber mal etwas anders formuliert: den Server selbst sollte man am besten nicht öffentlich zugänglich machen. Besser per VPN erreichbar machen, auch so kann man dann Mal von unterwegs darauf zugreifen. Ist ein ganzes Stück sicherer. Einzelne Dienste/Docker kann man dann immer noch "frei" ins Internet stellen

Weil die bereits vorhanden sind oder wieso genau diese Konstellation? Bei 30TB Nutzdaten könnte man das ja schließlich auch mit weniger Disks lösen?!

Was kommt denn für ein Fehler?

Die äußern sich wie? Weil ich habe eine Fritzbox und bei mir läuft soweit alles?!

Damit kommst du eh nicht über C3😉

Jap, das ist leider korrekt. JMicron (egal ob 582 oder 585) mag kein ASPM. Wirklich unterstützt wird ASPM mWn nur vom ASM1166 und da bedarf es uU sogar noch ein Firmware Update.

OK, das man Pfade einem Docker hinzufügen muss, damit sie im zweifel auch dort nutzbar sind ist eigentlich das kleine Einmaleins... Aber freut mich natürlich, dass dir geholfen werden konnte

Also von Haus aus kann UNRAID das gar nicht. Hast du das s3 Sleep Plugin installiert? Wenn ja musst du das da abstellen bzw nach deinen Bedürfnissen konfigurieren.

Und das als erster und einziger Post. Ich weiß nicht...riecht ein wenig nach Troll. Zumindest aber Mal kein Interesse an Lösungsfindung. Denn wenn ich sechs Mal meinen Server neu aufsetzen müsste hätte ich glaube ich schon beim dritten Mal oder so was gepostet. Aber gut, jeder wie er mag und viel/mehr Glück bei anderen NAS Systemen

Naja, wenn du das bisher nicht aktiv geändert hattest, ist das standardmäßig eigentlich auf der SSD?! Ansonsten wenn eh noch keine Docker und vns existieren zur Not von der HDD einfach löschen und auf der SSD neu anlegen lassen (über settings->Docker bzw VM den Pfad entsprechend anpassen bzw die shares dann auf Cache only stellen)

Ich mache das per UAD in Verbindung mit dem rsync Script von @mgutt. Damit sichere ich täglich diverse shares auf einen externe HDD. Die HDDs werden zusätzlich monatlich getauscht (die zweite liegt immer auf der Arbeit, für den Fall von Feuer, Einbruch/Diebstahl etc). Und on Top sichere ich wichtige Dokumente, Bilder auch noch in die Cloud.

den vm.drity_ratio ? würde mich wundern wenn das jetzt der Bremsklotz war. Und beim RAM Cache immer bedenken, USV ist da quasi zwingend erforderlich. Denn es werden ja wesentlich mehr Daten im RAM gehalten. Geht dann plötzlich der Strom aus, sind die Daten weg.

Hm okay das sieht eigentlich gut aus. Könnte bei Powertop natürlich auch einfach nur ein Anzeigefehler sein, die realen "Steckdosen"-Werte sehen ja schon gar nicht so verkehrt aus

Vermutlich wird eines der Geräte (vielleicht sogar die SSD) kein ASPM unterstützen. Kann man mit lspci prüfen. Hab gerade nicht den genauen Befehl im Kopf. Aber wenn du hier im Forum bzw sogar in diesem thread mal nach lspci suchst solltest du fündig werden

Genauso funktioniert es. Einzig bezüglich der mit zunehmender Diskanzahl steigenden absoluten Ausfallgefahr, könnte man irgendwann (individuelle Entscheidung, mMn erst wenn Datendisks in zweistelliger Anzahl vorhanden sind) über eine zweite Parity Disk nachdenken.

Zum "heilen" musst du jetzt ersteinmal das Array als secondary storage definieren, dann mover direction "Array->Cache". Dann unter settings -> Docker den Docker Dienst stoppen. Danach den mover starten Dann Docker Dienst wieder aktivieren und ggfs den Share wieder nur auf Cache stellen

Definitiv nicht. By Default liegt der im Cache. Hast du den Cache eventuell bei der UNRAID Ersteinrichtung noch nicht installiert gehabt und erst nachträglich hinzugefügt?

Naja man könnte auch 2Tb SSD als Cache plus 2Tb HDD im Array ohne Parity und dann die SSD manuell auf die HDD sichern. Dann läuft dauerhaft nur die (idr deutlich sparsamere SSD) und einzig für das "Backup" (ein Backup sollte halt nicht im selben Gehäuse stecken, deshalb die Gänsefüßchen) wird dann die HDD aufgeweckt. SSD Preise sind zwar wieder gestiegen, aber das dürfte immer noch ein überschaubar finanzieller Aufwand sein und wäre vermutlich die sparsamste und gleichzeitig performanteste Lösung

Das ist das Fuse Dateisystem von UNRAID. Heißt aber auch dass da massiv Schreibvorgänge aktiv sein müssten, wenn das dauerhaft so aussieht?!

/dev/dri ist beim Container durchgereicht? Und Intel GPU Treiber direkt in UNRAID ist installiert (zb Intel GPU top von @ich777)

Kommt halt aufs Szenario an. Unter (Voll-)Last hat(te) AMD Vorteile. Aber dafür sind die im idle leider wenig sparsam. Und die meiste Zeit ist so ein NAS / Homeserver eben dann doch eher im idle

Den jeweiligen Share anklicken, primary storage Cache, secondary Array, mover direction: Array -> Cache. VM Dienst und Docker Dienst beenden, mover starten Nochmal kontrollieren ob alles verschoben wurde Wenn alles gut: VM Dienst & Docker wieder starten Wenn nicht: die Brechstange rausholen und mittels mc verschieben und danach dann VM & Docker starten