hawihoney

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.

Bei 4x 4K hatte ich aufgehört zu lesen, daher auch von mir zunächst keine Antwort. @DataCollector hat Dir bzgl. Hardware geantwortet. Ich packe noch jahrelange Erfahrung mit Plex drauf. Hab "nur" einen Intel W-1290P mit P630 Grafik. Diese Grafikeinheit transcoded locker 1-3 4K Streams. Das kann hier schon mal vorkommen. 4x 4K hatte ich noch nicht, aber 3x 4K plus 1x 2K parallel hatte ich auch schon. Allerdings kann je nach Hardware etwas Unerwartetes zum Engpass werden. Stell Dir einfach vor, alle Streams kommen von der selben Platte. Und jetzt stell Dir zusätzlich vor Du hast "richtige" 4K Rips wie den folgenden: Größe: 51.274.617.534 bytes Bitrate: 73.281 Kbits/s Codec: hevc Width: 3840 Length: 2160 Da bräuchtest Du bei 4x 4K einen nahtlosen Stream von 300 Mbit/s inkl. permanentem Lesekopfwechsel von der selben Platte. Plex puffert zwar für den Transcoder vorab (ob und wieviel ist einstellbar) aber das kann dann an nicht erwarteter Stelle quietschen. TLDR: Der Plex Transcoder (FFMPEG?) im Zusammenspiel mit einer potenten iGPU ist ein Biest und schaufelt viel weg.

Das ist falsch. Ich vermute, dass appdata zunächst auf dem Array lag und später durch Dich auf den Cache umgezogen wurde. Prüfe mal bitte auf welchen Datenträgern der Wurzelordner von appdata so alles liegt. Der Log Ordner ist standardmäßig unterhalb von appdata:

Ahem, war nur ein Tipp auf Grund der Fehlermeldung. Kann aber auch ein defekter Port sein. Wie auch immer: Gewöhn Dir bitte an, die Leute richtig zu "quoten". Ich sehe Deine Antworten immer nur durch Zufall. oder

Ich hatte gedacht Du meintest rote SMART Werte. Oben zu sehen ist aber ein Auszug des syslogs. Egal. Ich fürchte hier muss jemand Anderes, der eher der Hardware Fraktion zuzuordnen ist, einspringen. Hab nur das gefunden bzgl der EMask - und das klingt nach defektem Kabel: Lösungsschritte und wie man den Port identifizieren könnte, findest Du hier: https://www.thomas-krenn.com/de/wiki/SATA_exception_Emask_0x10_SAct_0x0_SErr_0x4000000_action_0xe_frozen

Screenshot posten.

Viele - meist unsauberes Herunterfahren. Aber das wüsstest Du, denn dann startet automatisch ein Parity-Check. Ein Unraid Update ändert nichts an Deinen Daten, das ist es garantiert nicht. Bei mir läuft der Check manuell so alle 3-6 Monate. Meist vor einem Unraid Update, Das erinnert mich daran. Guck Dir mal die Datenplatten im Explorer an, sind die lesbar? Wenn Du ein aktuelles Backup hast, dann könnte man das vorsichtshalber zurück spielen. Und nein, Du wirst maschinell nicht erkennen können welche Daten korrigiert wurden.

Sorry, kleine Korrektur. Ich weiß, dass Du das kennst. Will nur vermeiden, dass das die Runde macht. So wäre es korrekt gem. der UNC (Uniform Naming Convention): \\Servername\blablabla https://de.wikipedia.org/wiki/Uniform_Naming_Convention Hier sieht man wie die Notation angewendet werden könnte: # # Als Windows Admin auf der Konsole ausfuehren # C: CD \ MKDIR "Privat" MKLINK /D "C:\Privat\Bilder" "\\Tower\disk1\Bilder"

Stimmt und stimmt nicht. Zwischen den Prüfungen werden nur Blöcke, die verändert werden, geschrieben und somit gecheckt. Der Parity-Check ist für die komplette Überprüfung - auch der Altdaten. Ich weiß nicht wie die Seite im Deutschen heißt, aber meiner Meinung nach hast Du das Dashboard und nicht die Haupt-Seite gepostet. Mit geht es um das Dateisystem und evtl. angezeigte Fehler - das zeigt das Dashboard nicht.

Natürlich nicht. Der Inhalt der Daten-Platte(n) stimmte nicht mehr mit dem Inhalt der Parity-Platte(n) überein. Sofern das ein korrigierender Parity-Check war, und das ist er standardmäßig, wurde der aktuelle Inhalt der Daten-Platte(n) bei den Parity-Platte(n) korrigiert. Das garantiert, dass bei einem Ausfall einer Daten-Platte diese wieder rekonstruiert werden kann. Über die Ursachen von einer riesigen Menge Sync-Fehler kann man nur spekulieren. Eine Daten-Platte am Rande des Kollaps, Kabel-Verbindungen zu den Platten, etc etc. Selbst Schrott auf Daten-Platte(n) kann in diesem Zustand nicht ausgeschlossen werden. Das Array in sich ist jetzt wieder im Lot. Aber das sagt nichts über den Zustand der Daten aus. Guck Dir mal in der Unraid Oberfläche die SMART-Werte der Platten an. Gibt es Fehlerhinweise z.B. UDMA*. Wie sind die Platten angebunden? Bei USB bin ich aber sofort raus. Mach mal Screenshot von der Hauptseite.

Dieser Autor hat Unraid nicht verstanden. Mehr kann ich dazu nicht sagen. Meine Abneigung gegen die allgegenwärtigen Youtube Videos kennen ja die meisten bereits. Diese Videos enthalten Meinungen - keine Fakten. Will ich Fakten und Details dann sollte man, als Server-Betreiber muss man, die Original Doku lesen und verstehen. Youtube Videos sind halt bequem - aber nicht zwangsläufig richtig. 'nough said.

Ach daher kommt das. Ich hatte zuletzt das Gefühl, dass nur noch über USB Devices im Array geredet werden muss. Das hat zuletzt keinen Spaß mehr gemacht. Hier im Forum sollte bei einer Supportanfrage, wie auch im General Support Forum üblich, als erstes nach der Diagnostics Datei gefragt werden. Sind USB Platten im Array oder Pool, dann schreibt man das und der Support sollte an dieser Stelle erst mal enden. Alles Andere verbrennt meiner persönlichen Meinung nach die freiwilligen Helfer.

Ist Deine Installation denn wirklich so komplex? Meist reicht es doch den Ordner /custom_components/ plus den *yaml und *.db* Dateien aus dem Hauptordner zu übernehmen. Könntest Du ja mal spaßeshalber ausprobieren: lscr.io/linuxserver/homeassistant installieren aber nicht starten, dann die o.a. Ordner und Dateien aus einer Sicherung drüber klatschen und Container starten. Einen Versuch wäre es wert. Bei mir wäre es alles Gelbe:

USB im Array ist einfach Mist. Was das hier schon an Support Anfragen verursacht hat geht auf keine Kuhhaut. USB Devices hängt man über Unassigned Devices rein und gut ist. Parity geht dann zwar nicht, aber dann rsync't man eine Platte halt via User Scripts zeitgesteuert auf die zweite Platte. Egal wer USB im Array empfiehlt, der hat sich nicht wirklich mit Unraid bzw. md auseinandergesetzt. Hab letztens gehört Heise hätte das empfohlen - ich kann das nicht wirklich glauben ... Ist halt ein Unterschied ob man Parity in Echtzeit pflegt (Unraid) oder manuell/zeitgesteuert (z.B. SnapRAID). Jeder kurze Aussetzer in der Verbindung, den man via Unassigned Devices nicht mal merken würde, lässt das Array stoppen - und das muss so sein. Bei mir baumelt auch eine USB WD Elements im Lüfterauslass am Server und ist via Unassigned Devices als Ziel von NZBGet glücklich. Im Array wäre das selbe Device bestimmt schon dutzende Male rausgeflogen.

Wenn Du ein Array mit einer Parity-Platte und einer Daten-Platte aufbaust, dann ist meiner persönlichen Meinung nach der Preclear völlig überflüssig. Unraid wird auf beiden Platten ohnehin jedes Bit beschreiben. Fehler die bei einem Preclear auftreten würden kämen dann auch zu Tage.