hawihoney

Ohne das von Dir modifizierte Script, oder einen Link auf das von Dir 1:1 eingefügte Script, wird Dir vermutlich niemand helfen können. Das offizielle Format für ein Device Skript findest Du im ersten Beitrag in diesem Thread:

Nein, nein. Du formatierst i.d.R. nix selber. Die Fehlermeldungen von Unraid genau lesen, die Hilfe '?' einschalten und auch diese lesen. Im Zweifel hier fragen. Meine persönliche Meinung: Finger weg von den Youtube Videos (ausgenommen SpaceInvaderOne). Denn es ist nicht garantiert, dass alle diese Nasen Unraid verstanden haben. Es gibt nichts, was nicht im Unraid Forum (englisch oder deutsch) geklärt werden kann. Hier findest Du die Developer, Community Developer und freiwillige Helfer mit teilweise vielen Jahren Erfahrung. Diese Unsupported Filesystem Meldungen kenne ich hier aus dem Forum eigentlich nur nach harten Abstürzen (größtenteils BTRFS Pools). Ansonsten habe ich keinen Schimmer und kann nur auf Hardware, z.B. Verkabelung, tippen.

Die Kardinalfrage ist aber, war sie beim Formatieren im Array oder nicht. Wenn ja, dann wurde die Formatierung dieser Platte bit für bit auch in die Parity gespiegelt. Die Platte ist dann formatiert, leer und kann auch nicht mehr mit den alten Inhalten emuliert werden.

Und das verwirrt mich jetzt. Wenn Du sagst, dass die alte und vor Dir formatierte Platte wieder im parity-geschützten Array ist, und wenn dann alle Platten im Array grün sind (nicht emuliert), und die Inhalte der alten Platte noch vorhanden sind (auf /mnt/diskx/ prüfen), dann hast Du etwas anderes gemacht als oben beschrieben.

Das ist falsch. Da wird nix formatiert. Wenn eine Platte im parity-geschützten Array defekt ist dann wird sie von Unraid emuliert. Dann stoppt man das Array, fährt den Rechner runter, baut die alte Platte aus, baut die neue Platte ein, startet den Rechner, wählt in der GUI in der Dropdownliste des Slots der alten Platte die neue Platte. Unraid will dann eine Bestätigung beim Start des Arrays. Dann wird die neue Platte komplett mit jedem Bit der alten Platte beschrieben. Der alte Inhalt beinhaltet ja bereits die Formatierung der alten Platte. Deshalb wird beim Rekonstruieren nicht formatiert. Wenn man selbst formatiert ist alles verloren. Die Warn-Hinweise weisen auch darauf hin. Bitte lies Dir in Deinem eigenen Interesse meinen Link oben durch. Ich entnehme Deinen Aussagen, dass Dir noch nicht klar ist wie das Unraid Array und die Parity funktionieren. Wenn Du die alte Platte formatieren willst um sie dann Unraid wieder als Neu zu verkaufen, dann darfst Du das nicht im laufenden Array machen. Die Platte muss dann außerhalb des Arrays formatiert werden (Stichwort: Unassigned Devices). Also: Wie bist Du GENAU vorgegangen?

Wenn die Daten-Platte mit aktiver Parity-Platte im Array formatiert wurde, dann ist die Formatierung auch in der Parity abgebildet worden. Da kann man nix mehr wiederherstellen. Alle Änderungen an Daten-Platten im Array werden in Echtzeit zusätzlich in der Parity-Platte durchgeführt. Ggfs. könntest Du noch versuchen Daten aus der Daten-Platte zu rekonstruieren. Recovery Werkzeuge könnten da vielleicht noch etwas retten. Mit denen kenne ich mich aber nicht aus. Da müsste dann jemand anderes helfen. https://docs.unraid.net/legacy/FAQ/Parity/#how-parity-works

Nein, bitte nicht. Deine Frage wurde ja beantwortet:

Weiß ich nicht. Das sieht bei mir im Linuxserver.IO Container so aus. Da der Homeassistant Container bestimmt schon 200 mal ohne Probleme neu gestartet wurde, sehe ich da keine Probleme. Reboots kommen hier nur beim Unraid Update vor - auch das war bisher kein Problem - dafür gibt's ja die serial. Aber wer fährt schon seinen Homeassistant Server für Stunden runter? Meine Variante könnte ich noch optimieren (s. oben) aber es läuft, so oder so.

Anderes Thema - hier geht es nicht um NGINX. Mach einen eigenen Thread auf.

Aber so was von. Poste mal diagnostics. So sieht das aus: [...] ata4.00: ATA-11: ST4000NE001-**** [...] ata5.00: ATA-11: ST4000NE001-**** [...]

Stimmt nicht. Bridging ist bei Dir on:

Fehler ist eindeutig. Release Notes zu 6.12.4-6 abarbeiten: https://docs.unraid.net/unraid-os/release-notes/6.12.4/#fix-for-macvlan-call-traces

Warum HA nicht als Docker Container. Es gibt nur ganz wenige Situationen in denen VMs für HA notwendig werden: Unsere Zigbee Devices am Conbee II Stick im HA Container. Jede Nacht wird der HA Container über das User Script Plugin runter gefahren, gesichert und wieder hoch gefahren: ... ... #!/bin/bash #arrayStarted=true #backgroundOnly=true #clearLog=true #noParity=true docker stop homeassistant rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/homeassistant/ /mnt/disk1/Backup/Tower/system/appdata/homeassistant/ docker start homeassistant

Bei mir natürlich nicht. Wie gesagt, solche Fehler gab und gibt es hier nicht. Parity Check läuft hier nur alle 3-6 Monate und findet grundsätzlich NULL Fehler. Wenn meine Systeme aber so "wackelig" wären wie ich hier von Euren lese, dann würde ich es wahrscheinlich auch regelmäßiger machen.

Danke, aber brauche ich nicht. DOS BAT wurde bei mir in den 90ern durch OS/2 ReXX abgelöst und so ging das immer weiter. Heute mache ich so etwas in Python. Ich bin mir nicht sicher ob ich den Dateicheck brauche. In 15 Jahren hat Unraid nicht ein einziges schiefes Bit gemeldet. Aber ich würde, wenn ich es machen würde, auf meine Art lösen.

Du machst das übers Netzwerk oder in einer VM? Warum nicht auf dem Server? Wäre vermutlich einfach zu bauen. Ich würde es wahrscheinlich plattformübergreifend in Python mit der hashlib Bibliothek und einer SQLite DB lösen, aber ginge wahrscheinlich auch in BASH: # Alle Verzeichnisse unterhalb von /mnt/disk1/ suchen # Jedes Verzeichnis mit dem Prefix "Ordner: " ausgeben find /mnt/disk1/ -type d -exec echo 'Ordner: ' {} \; Wäre mal ein interessantes kleines Projekt für mich ...

Ist teilweise hier beschrieben. Muss man sich wohl aus mehreren Quellen zusammenbauen. Zuerst würde ich in die syslog schauen. Dort müsste das Modell beim ATA Port stehen. Dann weiter: https://www.thomas-krenn.com/de/wiki/SATA_exception_Emask_0x10_SAct_0x0_SErr_0x4000000_action_0xe_frozen https://delightlylinux.wordpress.com/2019/08/02/how-to-find-a-hard-drives-sata-port-in-bash/

Der offizielle Unraid Button ist standardmäßig mit Korrektur. Irgendein Plugin: Wenn nicht standardmäßig mit Korrektur dann wäre das grob fahrlässig. Kann ich mir deshalb auch nicht vorstellen. ∆∆∆ Ist so gewollt: Manuell mit Korrektur, automatisch ohne Korrektur. Ich würde trotzdem gerne wissen wie 95.000 Sync Fehler entstehen können ...

Darf ich fragen was Ihr mit Euren Systemen so macht? Gestern einer mit 1,4 Millionen Fehlern. Du mit 95.000 Fehlern. Lasst Ihr Unraid mittels Stromstecker hart runter krachen? Oder was macht Ihr? Seit 15 Jahren nutzen wir Unraid. Selbst zu Zeiten als die Server noch nachts runter gefahren wurden gab es so etwas bei uns nicht. 1x schief sitzender HBA nach einem Umzug, 1x Markisen-Bauer an der Steckdose, 1x durchgerosteter Stecker an der Brunnenpumpe. 3x, das wars, in 15 Jahren. Wenn ich mich richtig erinnere ergab das "nur" maximal 1400 Sync-Fehler. Echt, ich verstehe es nicht.

Kleine Korrektur: Das ist der Standard. Wenn die Korrektur nicht gewünscht ist, dann muss der Benutzer das explizit wählen. Das ist bewusst so geregelt, da ein vom Benutzer tolerierter Unterschied zwischen Parity- und Daten-Platten, beim späteren Ausfall einer Platte, zwangsläufig zu weiteren Fehlern beim Rekonstruieren führen wird. Unraid geht nämlich beim Rekonstruieren davon aus, dass die Parity stimmt. Wenn das nicht der Fall sein sollte, dann eskalieren Fehler unter Umständen auf bislang nicht betroffene Platten. Ich wiederhole: Stimmt die Parity nicht, dann rekonstruiert das System unter Umständen neue Fehler auf bislang korrekte Platteninhalte!

Prima. Solution-Markierung nicht vergessen

Die cwd (change working directory) DIR zählen nicht. Der shfs kümmert sich um etwas anderes. Bleiben 3 rsync Einträge übrig. Drei aufeinander folgende Nodes. Hmm. Da muss boniel mal drauf gucken. Im Moment würde ich sagen ist ok so. Ich nutze zum umfangreichen Kopieren/Verschieben eigentlich immer mc in einer screen Session. DFM nutze ich überwiegend nur um mal eben schnell etwas zu löschen. Kannst Dir spaßeshalber die Zeitstempel der betreffenden Dateien auf disk1 anschauen. Verändern die sich alle oder nur einer?

Kannst Du das mal mit lsof gegen checken? Sind die Dateien auf dem Ziel alle gleichzeitig offen?

@bonienl Can you please have a look at that htop shown above. Is it intended behaviour that multiple directories are copied/moved by multiple processes in parallel - even when copying/moving to the same target?

Kann, muss nicht. Noch einen Nachtrag zu Eurer Diskussion zum RAM oben: Bei vielen Transcodes "brennt" natürlich der Pool auf dem appdata mit dem Plex Ordner liegt. Das kann dann je nach Device auch "quietschen". Den Transcoder kann man bei ausreichend RAM vom Device ins RAM umbiegen. Aber das würde natürlich auch eine entsprechende RAM Ausstattung benötigen. Ich würde zunächst hinterfragen ob das wirklich in der Größenordnung bei Dir auftreten wird.