mgutt

Prefer. Bei Prefer landet nur was auf dem Array, wenn der Cache nachträglich hinzugefügt wurde oder der Cache mal voll gelaufen war. Aber wie schon gesagt wurde, einfach Docker/VM auf No und Mover starten.

Also die Scripte selbst waren in Ordnung? Python selbst war kaputt?

Genau das hätte ich gerne gewusst. Aber wenn ich das hier richtig verstehe, dann ist die Schreibweise komplett unterschiedlich, weshalb man gar nichts in Python 2 schreiben kann, was nachher auch in 3 läuft: http://python-future.org/automatic_conversion.html Also lieber gleich in 3 schreiben und evtl alte Scripte durch den Konverter jagen.

Die Frage ist, wenn ich heute ein Script in Python 2 schreibe, worauf ich achten muss, damit ich Probleme beim Update vermeide.

Worauf muss man in Python Scripten achten, weshalb die nach dem Update nicht mehr gehen?

Hier findest du eine Liste mit besonders sparsamen Komponenten: https://www.hardwareluxx.de/community/threads/die-sparsamsten-systeme-30w-idle.1007101/ Was davon Sinn macht hängt vom persönlichen Bedarf ab: - wie viele SATA Ports (ich würde direkt ein Board mit mindestens 6 nehmen) - wie viele M.2 (2 werden empfohlen für einen ausfallsicheren Cache) - ECC RAM ja/nein Nur als NAS kannst du auch einen RPI mit OMV betreiben. Der Reiz an unRAID sind die weiteren Möglichkeiten. Und schon macht unRAID Sinn. 😉 Hängt vom Board und Stick ab, aber ja, so schnell wie Windows bootet unRAID nicht, weil bei jedem Boot das OS komplett neu installiert wird. Neben WoL wäre noch die Frage ob Sleep reicht. Dafür gibt es ein Plugin. Mit einem C246M-WU4 kommst du mit 4 stehenden Disks aber auf unter 10W. Keine Ahnung ob dir das schon zu viel ist.

Ich lasse gerade den Stresstest laufen. Verbaut sind die folgenden 4 SSDs: 2x SanDisk Ultra 3D 4TB 1x Western Digital Blue SSD 3D 1TB 1x SanDisk Ultra II 240GB Aktuell befülle ich alle parallel, was wie man sieht auf allen ein paralleles Lesen und Schreiben auslöst. Mit ~200 MB/s parallelem Lesen und Schreiben ist die Parität aber immer noch ordentlich schnell. Muss man jetzt sehen ob es mit der Zeit langsamer wird, wenn die SSDs voller werden: Als Script nutze ich das: #!/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 Wenn der fertig ist, werde ich alle Dateien löschen und das ganze wiederholen. Da kein TRIM ausgeführt wurde, sollte der zweite Durchgang dann ja deutlich langsamer sein. Theoretisch. EDIT: Nach 2 Stunden. Die kleine SSD ist voll und es wirkt so als wäre nicht die Parität im Limit, sondern die Array Disks, da diese genauso schnell sind wie zuvor?! EDIT: Alles gelöscht und 2. Lauf. Man sieht einen deutlichen Performance-Einbruch: Beim 3. werde ich nach dem Löschen der Dateien etwas Zeit verstreichen lassen. Vielleicht greift dann die Garbage-Collection der SSD selbst und die Geschwindigkeit erhöht sich wieder.

Welche Pfade sind bei dem gemountet? Der sollte natürlich nur das beeinflussen können, worauf er überhaupt Zugriff drauf hat.

No pity with these ^^

Don't need to. Change to Dir and then Apps > Previous Apps to install them as before. The only thing what happens is re-downloading the packages. Any if you created such, you need to recreate custom networks. But you don't need to change templates or similar things. The docker.img does not contain any important data.

Dann wäre mein Vorschlag sie wie gesagt /.Seriename (2021)/ zu nennen. Plex indexiert sie nicht und nachdem die Folgen automatisch benannt wurden, entfernst du den Punkt einfach. Dann sparst du dir das Hin und Her.

Und was macht TinyMM mit dem Rip? Benennen oder was? Ich benenne bereits beim Rip, daher sehe ich aktuell nicht den Bedarf. Bei mir geht es direkt ins Ziel und was ich an Bonus-Inhalten erstmal nicht benennen möchte, das benenne ich ".bonus1.mkv". Also unsichtbar für Plex.

It will be less with XFS, but 12MB/s (sure?!) is too much for writes to log files. Your problem lies somewhere else.

Darf ich fragen was zwischen Rippen und Fertig passiert? Also warum überhaupt das Verschieben?

Du kannst eine dGPU entweder nur in einer VM oder für Docker verwenden. Die einzige GPU, die beides kann ist eine Intel iGPU bis zur 10ten Generation. Denn sich dann GVT-g.

Kurz nach dem Booten braucht unRAID ein paar Minuten bis wirklich kein Zugriff mehr auf die Platten erfolgt. Das könnte ich mir dadurch erklären.

Appdata ist doch bereits ein separater Share für Container Dsten?!

Das Appdata Backup Plugin macht genau das was du meinst:

Bitte deinstallieren und mit appdata cleanup die Ordner löschen. Danach noch mal über Shares > Ordner Symbol prüfen ob der entsprechende Ordner in appdata wirklich leer ist.

Hat er lange Zeit etwas gemacht oder war die Formatierung schnell erledigt. Im letzteren Fall könnte man es noch mit einer Datenrettung versuchen.

Ja, ist bei unRAID Standard

Ja. Was mir noch eingefallen ist. Solltest du mit der Zeit Performance-Probleme wegen dem fehlenden TRIM bekommen, könntest du auch einfach die 120GB SSD ins Array packen und mit den 1TB SSDs einen RAID Pool erstellen und alle Shares auf Cache Only stellen. Die 120GB SSD bleibt dann leer und im RAID funktioniert TRIM.

Da kann alles mögliche defekt sein. Die Sektoren auf der Platte, die Kabel, aber auch der RAM. Du hast keinen ECC RAM oder? Wenn nein, würde ich mal einen RAM Test machen. Es kann aber auch an Fehlern im BIOS liegen. Gibt es ein Update? Auch fehlerhafte Firmwares der Datenträger können Ursache sein. Weitere Ursachen können Stromsparmechanismen sein, wie zb ASPM.

Klingt komisch. Sind ja mittlerweile einige, die mein Template nutzen und solche Meldungen hatte ich noch nicht. Ich muss gleich eh noch was arbeiten. Wenn du dann noch wach bist, könnte ich Remote mal schauen.

3W = je nach DE Tarif 6 bis 8 € Ersparnis pro Jahr = ~5 Jahre bis zur Amortisierung.