alturismo

hier war es immer von ~ 70 - 80 MB/s auf > 200+ MB/s wie es auch sein sollte. habe ich eine SMR Platte dabei (gerade als Parity) dann hilft es wahrscheinlich weniger. wundert mich, aber ok, wird wohl in deiner Konstellation so sein. Ich kann es nicht mehr lokal quer testet da ich lokal keine Parity mehr nutze, bin komplett auf Spiegelserver umgestiegen für den Fall eines Ausfalls, aber mal schauen, zumindest einer der von mir "gewarteten" Server hat noch Parity.

Alternative wäre gewesen, Turbo write ON zumindest zum Befüllen https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/overview/#turbo-write-reconstruct-write dann hat man normal native Geschwindigkeit da nicht r/w/m parallel laufen muss, es laufen halt alle Platten dann, das sollte in Summe die schnellste Variante sein. ich schätze eher das ist disk i/o und nicht echt CPU Last, da wartet halt alles bis es weiter geht ...

soweit klar, nur wenn du einen rebuild startest dann schreibt ja einiges neu, sei es drum. Auszug syslog, disk4 hier war die noch da (mit Fehler falscher Key) hier nicht mehr ... sprich, da passt schon etwas nicht (als wäre die disk abgezogen, empty ...) mal egal wie das hier aus geht, in Zukunft sicher die Daten in so einem Fall zumindest lokal weg solange du im emulierten Zustand bist, wenn eine disk emuliert wird, von der disk die Daten weg auf ne andere disk im array (oder unassigneed, oder am Besten extern, oder ...) BEVOR man anfängt hier versucht zu reparieren ! (hier alles von disk4 auf eine funktionierende disk3 in einem vorhandenen Backup Verzeichnis) dann wären die Daten zumindest erhalten geblieben als Kopie, sollte nicht genug Platz sein, halt verteilen, danach dann die Reparatur starten.

ich glaube nicht dass das eine gute Idee war, vor allem wenn auch die Parity Fehler auswirft, dann einen Abbruch zu erzwingen ... Rebuild from Parity ist ja Block based, wenn da angefangen wird und dann abgebrochen wird, hmm. gefühlt würde ich sagen die disk ist jetzt teilweise überschrieben, aber nicht sauber. Versuch, die disk aus dem array entnehmen und per unassigned devices mounten und da versuchen zu retten was zu retten ist. normal würde ich sagen aus deinem Backup wieder einspielen, anhand der Fragestellung befürchte ich jedoch ist keines vorhanden ... ich bin jetzt weder zfs User noch LUKS, aber ich schätze das wird nicht einfach. @JorgeB may an idea, zfs and luks encrypted disk errored out from array, user tried to rebuild anyway, again errored while rebuilding, hard resetted several times, any ideas what to try to may resolve the data again, i suggested to try in UAD and try to mount and encrypt there, but i personally guess ...

your diagnostics, yes, but those looking fine, they dont contain the specific docker log, you can see them here as sample left click the docker icon, a menu will appear, logs ...

may rather take a look at the plex docker logs, from syslog side its looking ok, docker seems to start clean (system side) what likes to happen, sqlite issues with the plex database on a unclean shutdown, should appear in the plex docker logs.

Ich hätte mal noch gewartet (sorry), aber schauen wir mal ;) was mich halt wundern würde wenn es wirklich nur in dem Kontext passieren würde, anscheinend kommt das ja von hdparm dass der Zustand so ist (kein spindown möglich), sprich, die Hardware meldet das "warum auch immer" und es geht dann nichts mehr (auch manuell nicht). bis gespannt ;)

@MAM59 nur nochmals gefragt, sicher dass das nur passiert wenn die besagte Disk in einer Startup Gruppe ist ? sprich, wenn du keine Startup Gruppe nutzt passiert das nicht ?

der Ordner /mnt/user/system/docker ist auch nicht persistent, sprich, den zu kopieren macht wenig Sinn. die relevanten daten liegen auf /boot/config/plugins/dockerman/... Start Parameter deiner Dockers /mnt/user/appdata/... die effektiven persistent Daten der Dockers

it never "must" be off, its recommended to be off ;) in short, yes, always recommended on databases to turn off before you backup (replicate). for plex and its sqlite database, well, up to you, sample here, i am not stopping plex therefore, is it recommended, also here, yes if you want to be more failsafe. same goes for any backup solution you take

gibt es immer, ist der "array only" Zugriff bei einem Share Bsp, cache nvme (pool) und array, Share "Daten" /mnt/user/Daten zeigt alles an, egal ob die Daten auf dem ssd pool oder array sind /mnt/user0/Daten zeigt nur das array an (HDD)

naja, wenn die Software da was ansteuert, würde ich dort mal anfragen, Bsp. issue aufmachen https://github.com/SasaKaranovic/OpenFanController/issues wenn es mit der alten Version (Kernel) ging, dann ggf. mit angeben.

@JorgeB may a hint what this is as soon this happens a spindown from this disk is prevented, either manual or traggered. thanks ahead for a hint

powertop-2.15-x86_64-1.txz hier das Paket, Ordner erstellen auf /boot/extra, dort rein packen dann Neustart oder im unraid terminal dann im terminal alles in /boot/extra wird beim Neustart installiert, sprich, ist dann persistent, den Befehl dann entweder 1/ in die go Datei, liegt unter /boot/config oder 2/ user script erstellen (wenn das plugin installiert ist) und ein script mit dem Eintrag, als schedule "at first array start only" dann wird powertop immer beim Start installiert und auch entsprechend ausgeführt.

es gibt keine klassische Systemplatte, nicht das du einen Denkfehler "mitschleppst", auch keinen "cache" im klassischen Sinn. es gibt pools, die richtest du dir ein, ob da jetzt "Systemdaten" liegen oder neue Daten "zwischengelagert" werden bevor diese verschoben werden, alles machbar, es gibt aber keine "flüchtigen" caches und auch kein c:/ ;) dann wie beschrieben, einfach löschen und auf dem gewollten pool neu starten, fertig, denk nur dran auch die /appdata auf den passenden pool zu legen, bei vm's auch /domains usw ...