mgutt

Ja. Screenshot machen, damit du weißt welche die Parity HDDs waren.

Ja. Standardmäßig gehen sie nicht schlafen.

Theoretisch möglich. Wenn dir das zu riskant ist, musst du eben eine neue Platte kaufen. Eine leere brauchst du.

Wurde in den syslog ein Eintrag hinzugefügt? Dann wüsste man ja, dass das Script überhaupt ausgeführt wurde.

Nothing. You need to execute powertop and check the c-states as mentioned in the first post.

You can't permanently change files that are inside of a container. That's why you should create a cnf file in "/mnt/user/appdata/mariadb-official/config" as described in my last post. This path is mounted through the container, so files in this path aren't lost if the container is restarted / updated as it would happen to files in /etc/mysql It does. You probably used the unRAID Terminal instead if the container's console?!

Liegt wohl an deinem Motherboard / BIOS: https://forums.unraid.net/topic/87929-unraid-changes-bios-clock-time/?tab=comments#comment-818026 Gibt es ein BIOS Update? Ansonsten mal gezielt nach deinem Board recherchieren mit "UTC" bzw "NTP".

Kann durchaus sein. Einfach bei den Shares rechts aufs Icon klicken und die Location prüfen. Da muss dann Cache stehen und keine Disk. Auch die Frage, ob du in den Disk Settings das Delay gesetzt hast?!

Der 1700x Build dürfte alleine >20W ziehen. Und welchen Sinn hat OpenSense, wenn es nicht 24/7 läuft?!

Nein. Ist in unRAID enthalten.

Open the console of the container and execute this: cp /var/tmp/dropbox_errorsn1t4ito.txt /opt/dropbox/.dropbox/errors.txt Download the file through /mnt/user/appdata/Dropbox and upload it here.

Also du nimmst jetzt den OptiPlex und parallel einen 1700x Build? Bezahlst du nichts für Strom oder wie kommst du nun auf diese Konstellation?

Genau. Dann könnte man RTC Events hinzufügen, die die Hardware wecken:

Ich habe meine Testergebnisse nun in einen separaten Thread gepackt:

Da mich das Thema interessierte, habe ich ein paar SSDs genommen und ein paar Benchmarks im Array gemacht. Das verwendete Script, das ich für jede Disk ausgeführt habe: #!/bin/bash for n in {1..380}; do head -c 10000000000 /dev/zero | openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt > /mnt/disk1/file$( printf %03d "$n" ).bin done Im ersten Test habe ich auf allen SSDs gleichzeitig geschrieben, was im Alltag eher unrealistisch sein dürfte, aber zeigt wie wichtig die Performance der Parität ist: Danach habe ich alles gelöscht und den Test wiederholt. Hier kommt nun der Nachteil zum Tragen, dass Unraid keinen TRIM im Array ausführt und dass man die Parität auch gar nicht trimmen kann (da die Parität zu 100% mit RAW Daten und keinen Dateien beschrieben wird): Die Parität bremst nun also das komplette Array. Diesen negativen Effekt hat man bei sehr guten SSDs, wie zB aus dem Enterprise Bereich, weniger, da diese einen (großen) Over-Provisioning Bereich besitzen, der für den Nutzer nicht sichtbar ist und auf dem beim Durchlauf der Garbage Collection Daten zwischengespeichert und aufgeräumt wird. Wartet man diese Garbage Collection ab (der SSD Controller macht dies automatisch in Leerlaufphasen, lässt sich nicht manuell anstoßen), dann werden die SSDs tatsächlich wieder schneller: Gar keinen Leitungseinbruch gibt es erwartungsgemäß beim Lesen von einer SSD mit dem folgenden Kommando: dd if=/mnt/disk1/file001.bin of=/dev/null bs=128k iflag=count_bytes count=10G Dann habe ich aber auch mal nur auf eine SSD geschrieben, so dass nicht parallel mehrere Paritäten berechnet werden, sondern nur eine, aber trotzdem limitiert hier das parallele Lesen und Schreiben: Hier wären NVMes natürlich viel schneller. Es gibt Modelle, die fast 2000 MB/s beim parallelen Lesen und Schreiben erreichen: https://www.computerbase.de/2021-04/wd-black-sn850-blue-sn550-test/2/#:~:text=Kopieren auf der SSD Allerdings kann man paralleles Lesen und Schreiben, solange man nur auf eine SSD im Array schreibt, vermeiden, in dem man in den Disk Settings "Reconstruct Write" aktiviert, was man bei SSDs auch machen sollte, da diese im Gegensatz zu HDDs im Millisekundenbereich in den Standby wechseln. Die Performance ist nun deutlich besser, da die Parität jetzt nur noch beschrieben wird: Sie kann aber noch besser sein, wenn man keine langsame SSD im Array hat, denn das schwächste Glied im Array bestimmt bei Reconstruct Write die Performance: Da ein TRIM die Parität zerstören kann, ist der TRIM bei Array-Disks übrigens deaktiviert: root@Tower:~# /sbin/fstrim -v /mnt/disk1 fstrim: /mnt/disk1: the discard operation is not supported root@Tower:~# /sbin/fstrim -v /mnt/disk2 fstrim: /mnt/disk2: the discard operation is not supported In meinen Fall wäre es zB sehr schlecht TRIM auszuführen, denn meine SSDs würde nach einem TRIM alle Sektoren mit Nullen beschreiben, so dass die Parität, die sich ja aus den Sektoren aller beteiligten Disks ergibt, direkt kaputt gehen würde: hdparm -I /dev/sde | grep TRIM * Data Set Management TRIM supported (limit 8 blocks) * Deterministic read ZEROs after TRIM "Deterministic read ZEROs after TRIM" nennt man RZAT. Man bräuchte stattdessen DRAT "Deterministic read data after TRIM". Dann würde die SSD nach dem TRIM weiterhin die selben Daten zurückgeben und die Parität bliebe valide. Wobei man natürlich auch überlegen könnte, dass man nach einem RZAT TRIM einen Paritätscheck mit Reparatur ausführt, aber in den Stunden ist dann natürlich die Gefahr gegeben, dass man keine Ausfallsicherheit hat. Aktuell versuche ich herauszufinden, wie man trotzdem einen TRIM ausführt (ohne jetzt das Array stoppen zu müssen und manuell zu mounten). Ich reiche dann auch davon einen Screenshot nach. Auch würde ich dann gerne testen was passiert, wenn man die Sektoren von gelöschten Dateien vorher mit Nullen beschreibt. Dann müsste ja theoretisch die Parität ganz bleiben. Vielleicht hat da jemand einen Tipp für mich.

https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?do=findComment&comment=951565 Fazit: Nutz prefer und der mover geht. Danach könntet du auf only stellen. Das bringt aber keinen Vorteil.

Wie jj1987 bereits sagte, liegt es am Controller im Stick. Ansonsten kann ich davon aber eh nur abraten, denn diese Controller unterstützen auch keinen Sleep. Dh die M.2 sind 24/7 pro Tag auf Vollgas, werden super heiß und erhöhen massiv den Stromverbrauch. Also wenn lieber über einen PCIe Slot gehen.

Wenn du das Array um 120GB vergrößern willst, dann ja. Verstehe ich nicht. Wozu willst du sie dann im Array verwenden?

Du meinst auf dem HDMI Ausgang? Wird nicht einfach. Die neue XE iGPU kann kein GVT-g mehr und wenn müsste man die iGPU daher komplett durchschleifen: https://dgpu-docs.intel.com/devices/iris-xe-max-graphics/index.html Ob das klappt, kann ich dir nicht sagen. Gibt zu wenig Erfahrungen dazu und kann von Hardware zu Hardware anders sein. Wie soll das bei gerade mal zwei LAN Buchsen gehen (die braucht ja alleine OpenSense)? Und was machst du, wenn OpenSense nicht läuft (= kein Internet)? Und warum willst du das? Alles von einem Gerät abhängig machen, wird am Ende einfach nur eine geringe Verfügbarkeit der jeweiligen Services resultieren. Das ist so als würde man das Kochfeld abschaffen, weil man ja auch im Backofen kochen kann. Gibt es nur Geld für eine Hardware, dann schmink dir das Projekt ab. Willst du Strom sparen, dann kauf gebrauchte Unraid-Hardware und nutze WoL. Den Mini-PC dann eben klassisch als Thin-Client nutzen. Für OpenSense dann entweder passende Unraid-Hardware erwerben oder auch dafür separate Hardware nutzen, was auch grundsätzlich meine Empfehlung wäre.

Ich brauche eine GUI um Sync Jobs von mehreren Verzeichnissen zu verwalten, die automatisch nach Zeitplan laufen. Allerdings wäre Quelle und Ziel externe Server. Ich bräuchte also einen Container wo ich nicht von lokal nach extern syncen kann, sondern von extern nach extern. Oder ich müsste immer zwei Jobs anlegen. Die einzige Bedingung ist, dass man 1:1 Sync oder verschieben einstellen kann. Jemand eine Idee was man da nehmen könnte? Darf auch Geld kosten. Als App in einer VM wäre auch ok. Gefunden habe ich bisher nur Goodsync. P.S. Richtig genial wäre, wenn ein Verzeichnis als ZIP per Email versenden könnte, aber das könnte ich auch selbst scripten.

Datenträger anklicken und dann bei den SMART Werten schauen.

Schon öfter, aber hat ja @jj1987 schon gesagt, dass man da eine Ausnahme einstellen muss.

Vom Prinzip ist Ubuntu vs Alpine der selbe Vergleich wie Apache vs Nginx. Das eine benötigt mehr Ressourcen und kann mehr, aber bietet dadurch auch mehr Angriffsfläche.

Nein zwei. C246M-WU4 oder W480M Vision. Beide sehr gute Boards mit ECC Support. Ohne ECC gibt es deutlich günstigere Boards. Achte nur darauf, dass du keine SMR kaufst. Ansonsten kannst du kaufen was du magst.