_alo_

Nein, geht ja auch gar nicht 😉 Die picopsu ist quasi schon onboard verbaut, das ist ja der Vorteil des „DC“

ja genau und docker-/VM-Dienst stoppen Das reicht ja auch völlig, ich hab in meinem Thread auch mal AVM/shelly/tasmota verglichen.....die tun sich kaum was. Idealerweise hast Du davon aber einen zeitlichen Verlauf, wo Du auch Veränderungen in z.B. einer Stunde sehen kannst.... Wenn Du HA eh runterportieren willst, bist Du darauf ja dann bestens vorbereitet 😉

Wenn Du Zeit & Bock hast: Mich würde sehr interessieren, wie der i5 14400 (65W TDP) sich gegen meinen i3 12100 (60W TDP) im idle-Verbrauch schlägt. Wenn du also auch mal den Verbrauch des möglichst nackten Systems (also ohne Array und die vielen NVMes) wie ich messen könntest, wäre das cool. Da Du ja jetzt Board/Netzteil/RAM identisch zu mir hast, wären die Ergebnisse dann ja gut vergleichbar 👍

Der Standard (ohne Plugin) ist, dass der mover jede Nacht läuft. Was ist denn „nicht zu lange“ für dich, denn jetzt sprichst du ja schon von einer Woche? 🤔

Eigentlich gibt es den ja im Main tab aber wenn du dem mover über das Plugin dann sagst, dass er aber nichts machen soll, bringt das ja nix. Also Plugin wie gesagt am besten deinstallieren. Oder einen redundanten Cache aufbauen wenn du Daten da länger sicher vorhalten willst. Oder zusätzliche Backups dieser Cache Daten anlegen (zb stündliches RSync aufs Array) damit sie gesichert sind.

Gerade bzgl der unten angegebenen Prozentangaben: Wie voll ist dein Cache aktuell?

Das ist zwar richtig, nur frage ich mich dann ernsthaft, ob unraid dann noch das richtige System für Dich ist. Hier geht es ja primär darum, kein RAID mehr zu haben.... Die performance kommt hier ja eher vom Cache (hier ggf. auch gerne zfs bzw RAID) und das Array als Datengrab/Tier2 oder wie auch immer Du es bezeichnen willst wird eher über 1-2 parity-disks gegen Ausfall geschützt, aber die Platten zum lesen einzeln gestartet. Das spart Strom und schont die Platten im Gegensatz zu performanten RAID-Systemen, wo immer alle Platten zum Schreiben/Lesen laufen. Aber ja, Du kannst das schon so machen....

Waren da also noch leere Ordner auf deinem Pool?

Sorry mein Fehler, „Cache“ ist der default Name für den ersten Pool. bei dir heißt der Vm, daher dann /mnt/Vm/

Zusätzlicher Tipp falls nicht genug platz im Cache ist: kein Share über mehrere Array Platten verteilt nutzen! Timemachine hatte bei mir wohl Probleme, die Daten abzugleichen weil die einzelnen Platten evtl. zu langsam starteten? Seitdem ich den Share auf eine Single Datenträger (bei mir aus Stromspargründen eine große extra Pool-SSD) gelegt habe, läuft TM wieder dauerhaft!

Zumindest das von dir gewählte Board kommt (wie fast alle Board der letzten Jahre) ja schon mit 2,5Gbps. Mit einem günstigen Switch bekommst du dann vielleicht schon einen Teil deines Netzes günstig immerhin auf 2,5G, weil andere PCs vermutlich ebenfalls schon 2,5G unterstützen… Ansonsten stimme ich data voll zu 😉 P.s. Auf der Suche nach einem passenden mATX Gehäuse bin ich gerade auch 🙄 das ist gar nicht so einfach wie zuerst gedacht, wenn mehr als 2-3 Anforderungen zusammenkommen und einem die Filtermöglichkeiten bei geizhals bzw die Ergebnisse nicht ausreichen… zusätzlich passende Bastelmöglichkeiten zu finden ist die Kür. Aber dazu mache ich mal einen eigenen thread auf…

Genau, war es nicht auch so dass unraid zb schaut, ob es den Ordner „Filme“ auf dem (Single) Cache gibt, also /mnt/cache/Filme, und zeigt ihn dann als unprotected an, egal ob da Dateien drin sind oder er inkl. aller Dateien auf dem Array liegt und das Share auch Array-only eingestellt ist? Es werden ja dort nicht die shares angezeigt sondern die Ordner, ist das nicht immer noch so? Einfach nur die Ordner-Leiche reicht iirc schon aus für diese Anzeige weil unraid von der Reihenfolge glaube ich immer erst im Cache sucht …

Wenn ich direkt auf disk1 einen Ordner Manuell anlege wird dieser doch auch als Share in der Übersicht angezeigt, obwohl er nicht direkt als Share angelegt wurde, oder? Ist das vielleicht daher als Folge nur ein Anzeigeproblem? Ich meine sowas hatte ich auch schonmal….

Heißt das, es gibt auch shares die geschützt sind? Oder sind da einfach keine Dateien drin? Es kann eigentlich nur am Single Cache oder an fehlender Paritäten disk liegen. Oder arbeitest du evtl (z.T.) mit unaesigned devices? (Ich hab mir dir diagnostics nicht angesehen)

Das kommt halt darauf an, wie die Pfade in der Konfiguration jeweils gesetzt sind. Wenn die Daten von zb nextcloud unter appdata lagen und du diesen Ordner nicht mehr hast (wie es derzeit aussieht) dann blöd Wenn die Pfade hingegen zb ins Array zeigen, sollten die Daten ja noch da sein… Wenn du den Container neu anlegst, siehst du ja dabei auch die Pfade, wie sie vorher eingestellt waren…

Da sich die Konfigurationen der docker Container noch auf dem Stick befinden, ja, das geht so einfach. Die Container selbst werden beim anlegen dann neu runtergeladen. Aber die Daten (Appdata) fehlen dann weiterhin. DAS ist idr das eigentliche Problem. Dein Lancache muss dann halt wieder aufgebaut werden (was ja nicht schlimm ist, nur dauert), aber sowas wie Paperless wäre schon doof: da müsste man alles neu Einscannen… P.s. Bitte mache nur screenshots von dem Bereich was du zeigen willst und nicht immer vom gesamten bildschirm. Das macht es einfacher das wesentliche zu erkennen, besonders auf Handys.

oder wenn der mover nichts verschoben hat, man die Ordner gar nicht mehr hat (Formatierung), und die Dienste neu startet.... Meine Vermutung ist eben, dass das Moven der Systemshares appdata/system eben nicht geklappt hat, bevor er den Cache formatiert hat.

Ja genau, irgendwann kommt der Punkt an dem die neue RAM Technologie preislich attraktiv wird weil die ältere erst verdammt günstig wird (Abverkauf) und dann stark anzieht (verknapptes Angebot, „mangels Nachfrage“). Vielleicht sind wir kurz davor, dann muss ich mich noch eindecken 😏 Ja ich weiß wo du den her hast, warum, und dass er nicht unter unraid eingesetzt wird von dir. Ich wollte die Frage trotzdem mal loswerden (auch für den TE), weil ich die Infos auf der crucial Homepage etwas dürftig finde bzgl xmp/spannung/etc Ich setze ja auch keinen xmp ein und hab das aus Gründen auch nicht vor.

Werden die System Shares nicht auch neu erzeugt wenn nicht vorhanden und man die Dienste startet?

Eigentlich nichts, sind zwar auch 120€ für 64GB aber das is ja noch ok. Mushkin muss es natürlich nicht sein, aber da ist der Anstieg halt sehr extrem. Hast du nicht auch die pro? Die sind ja aktuell bei 64gb noch 5€ günstiger als die normalen - wird hier das xmp benötigt und läuft er auch danach noch mit 1.2V?

weißt Du, was der Mover ist und was er macht und was man dazu wo einstellt?

Dazu wäre dann eben die Share Einstellungen interessant und vor allem, was Du dort wann wie geändert hast. Wir hatten hier auch schon Fälle, dort hat einfach jemand den primären Speicher für neue(!) Dateien geändert und ging davon aus, dass dadurch alte Dateien verschoben werden.... Dazu wären wie schon gefragt, mehr Details hilfreich: vielleicht war das auch kontraproduktiv? was genau hast Du denn gemacht. Edit: ich hab mir die Anleitung (https://docs.unraid.net/unraid-os/manual/storage-management/#backing-up-the-pool-to-the-array) nochmal kurz angesehen und wieder festgestellt, dass LimeTech diese nicht wirklich auf Stand hält. Zum einen ist da noch zwingend von BTRFS die Rede (zfs fehlt) und dann ist das Umstellen der Share-Einstellungen für Anfänger auch nicht wirklich verständlich, oder? im Punkt 4 heißt es Das sind Einträge von alten unraid-Versionen, das heißt heute nicht mehr so. Was das eigentlich bedeutet: man sollte den sekundär-Speicher definieren und eine Mover-Action, die die Daten dahin verschiebt, etwa so: und dann den Mover ausführen. Wenn man dann in dem Tab Shares auf das Browse-Symbol vor dem Share-Namen klickt, sieht man auch in der "Location"-Spalte, wo sich die Dateien/Ordner befinden. Wenn man den Cache dann umgebaut hat, reicht es eigentlich, die Mover-Action umzustellen auf "Array --> Cache", den mover auszuführen und dann landet alles wieder auf dem (neuen) Cache.

Wie @alturismo schon schrieb: Formatieren = Datenverlust. Wenn Du vorher die Daten mittels mover oder manuell verschoben hast, sind sie noch da, sonst eben weg-formatiert. Das sollte auch in jeder Anleitung so drinstehen... Dann hilft nur ein Backup (was man eh haben sollte). Ich kann dazu das Plugin "Appdata Backup" empfehlen. Wie denn? Wenn Du das Share umstellst, passiert erstmal noch nichts! Du musst dann schon den mover manuell starten oder bis zum automatischen Durchlauf (standardmäßig jede Nacht) warten und dann danach am besten kontrollieren, ob Deine Daten auch noch da sind, wo Du sie haben möchtest, bevor Du Datenträger löschst (formatierst).

Uih 😳, krass, das hatte ich noch nicht mitbekommen ☹️ Mist, das ist mein Mushkin 64GB: Ich hatte meinen im Januar und April gekauft, dann nochmal überlegt, noch was nachzukaufen, da war er erst nicht lieferbar, dann auf 110€ gestiegen und ich dachte er geht wieder runter....dann vergessen.... Und jetzt?? Puh.... Mal sehen ob sich das mit DDR4 noch wieder erholt oder ob jetzt dann doch (preislich) langsam die Zeit für DDR5 gekommen ist....

Naja, wenn Du schon so lange dabei bist, sollte Dich die Angabe von "Supports 14th, 13th & 12th Gen Intel® Core™ Processors (LGA1700)" beim Board in Verbindung mit einem i5 14400 vor keine große Herausforderung stellen 🤔 Beim RAM würde ich zwar auf XMP Modelle verzichten, da sie manchmal Spannung hochdrehen müssen (und somit mehr Strom verbrauchen), um ihre Specs zu erreichen, die man wahrscheinlich eh nicht braucht. Ob das hier bei diesem "Blechdeckel"-RAM auch so ist, weiß ich nicht (CL22/3200Mhz erreicht mein JEDEC Mushkin Essentials auch bei 1,2V für knapp 100€), aber Dein gewählter sollte auch funktionieren. Ist ja nu keine wirkliche rocket-science, Sockel 1700 und DDR4 zu kombinieren. Wenn Du 100%ig sichergehen willst, schau in die Kompatibilitätslisten von Asrock. Gut, ich hatte nur auf deine Angabe PCIe5.0 X4 reagiert. Wüsste z.B. auch nicht, wozu man ca. 15GB/s (ja Byte, nicht Bit) im Server benötigt....😉