hawihoney

Die Parity Platte(n) wurden angepasst. Deshalb gibt es keine Fehler mehr. Grundsätzlich hat die Daten-Festplatte immer Vorrang. Es wird nie beim Parity-Check auf eine Daten-Platte geschrieben (die technischen Ausnahmen wie das Schreiben auf Reserve-Sektoren lasse ich mal außen vor). Es wird immer nur auf der Parity-Platte korrigiert. Beim Schreiben auf das Parity Protected Array werden die Platten in einer zeitlichen Abfolge bedient. Gibt es eine Differenz, dann ist "höchstwahrscheinlich" die Daten-Platte korrekt beschrieben und die Parity-Platte noch nicht. Selbst beim Abbruch des Schreibens auf die Daten-Platte gibt es dort "Selbstheilungsmechanismen" wie Transaktions-Logs die beim nächsten Boot einen konsistenten Zustand erzeugen. Deshalb läuft das immer so ab und deshalb ist es genau so auch richtig. Die Daten-Platte hat immer Recht! In extrem seltenen Ausnahmen, die eher durch Hardware-Fehler zu erklären sind, können die Daten auf der Daten-Platte defekt sein. Aber das läßt sich mit Bordmitteln nicht klären.

Bin halt "Alte Schule": So wenig wie möglich installieren, auf das Wesentliche reduzieren, ... Den FileManager wird wohl in absehbare Zeit jeder installiert haben. Ggfs. muss man in ihm nur weitere Extensions wie *.YAML anschalten (config auf Flash). Dann kann der quasi fast alles.

Geht auch über das stinknormale Dynamix File Manager Plugin. Da muß nix installiert werden.

Das kann ich so genau nicht sagen. Ich habe für jeden Container ein passendes User-Skript und die laufen täglich. Da sich darunter eine ziemlich umfangreiche Plex Installation befindet, und die Gesamtauslastung des Caches bei über 250 GB liegt, denke ich, dass es so in der Größenordnung liegt. Die Laufzeiten der Skripte hatte ich mal protokolliert und dementsprechend getaktet. Der ganze Zinober startet jeden morgen um 04:00. Das letzte Skript startet dann um 07:20.

Beim letzten Update wurde "Credits Detection" von Plex eingeführt und sofort scharf gestellt. Ein einfacher Test wäre, dieses Feature testweise und übergangsweise zu deaktivieren: https://support.plex.tv/articles/credits-detection/

Ja, 2-stufig. Das erhöht die Verfügbarkeit. 19 Sekunden aufs Array und die Container laufen wieder. Vom Array gehts nach extern. Wie lange das dann dauert spielt keine Rolle mehr.

Zum Beispiel MariaDB und Nextcloud in einem User Script - 19 Sekunden heute morgen. Ist das ein Problem? docker stop nextcloud docker stop mariadb rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/mariadb/ /mnt/disk17/Backup/Tower/system/appdata/mariadb/ rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/nextcloud/ /mnt/disk17/Backup/Tower/system/appdata/nextcloud/ rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/nextcloud.data/ /mnt/disk17/Backup/Tower/system/appdata/nextcloud.data/ docker start mariadb docker start nextcloud

Nur am Rande: Eine USB 2 Verlängerung kann in diesen Fällen helfen. https://www.amazon.de/gp/product/B00NH11R3I/

Im selben lokalen LAN?

Hängt gegebenfalls vom Container ab. Bei meinem Homeassistant Container geht das so: root@Tower:~# ls -go /dev/serial/by-id/ total 0 lrwxrwxrwx 1 13 Feb 9 12:21 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_XXXXXXXX-if00 -> ../../ttyACM0 Davon verwende ich diesen String: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_XXXXXXXX-if00:/dev/ttyACM0 Hier wird das als Value eingetragen:

Alle modernen Dateisysteme arbeiten wie Datenbanken mit "Transaction Logs". Beim Hochfahren werden diese geprüft ob unvollständige Aktionen (z.B. durch einen Absturz) korrigiert werden müssen. Die Platten starten also immer, das macht jedes OS automatisch beim Start. Stell die Spin-Down Zeit auf eine geringe Zeit. Ich habe 15 Minuten eingestellt.

Aus Deinem Text kann ich nur erahnen, dass es sich um zwei verschiedene Platten handelt. Ist der Parity Sync selbstständig abgebrochen oder hast Du den abgebrochen? Wie auch immer. Es sind mindestens noch alle Daten vorhanden die nicht auf den beiden ausgefallenen Platten liegen - das ist der Unterschied zwischen klassischen RAID Systemen und Unraid. Bei klassischen RAID Systemen wäre jetzt alles weg. Guck einfach mal auf alle individuellen Platten. Vielleicht kannst Du ja noch vieles retten.

Ist das ein Pfad im Container? Wenn ja, dann hast Du vermutlich das komplette Wurzelverzeichnis aller User Shares von Unraid in den Container gemappt. /mnt/user/ -> /media/mnt/user/ Und wenn das korrekt ist, dann kannst Du jedem Unterordner von /mnt/user/ individuelle Cache Einstellungen vergeben, da es sich bei den direkten Unterordnern von /mnt/user/ um Unraid Shares handelt.

Wenn Du das passende Package hast, dann kannst Du das mit seinen Abhängigkeiten in /boot/extra/ packen.

Interessant. Es gibt eine iSerial (00E04C239987). Wundert mich.

Hatte meine erste Antwort gelöscht, hatte mich auf den Conbee Stick bezogen - was falsch war. Was kommt wenn Du folgendes eingibst: lsusb -D /dev/bus/usb/001/006 Steht da irgendwo eine iSerial?

Was ist denn drin? Entweder in der Unraid GUI gucken oder: ls -l /mnt/user/user

So ist es auch. Du hast aber die Dinge in einer falschen Reihenfolge gemacht. Das entnehme ich es jedenfalls der Historie hier. Um eine Platte auszutauschen muss man nix anderes machen als: - Array stoppen, Rechner runterfahren - alte Platte raus, neue Platte rein - Rechner starten - In Unraid GUI die neue Platte dem Slot der alten Platte zuweisen - Array starten mit Haken an "Ja, ich bestätige Replacement Disk" Alles andere sind in meinen Augen esoterische Schritte die das Handling unnötig aufbauschen und für Anfänger verkomplizieren. Preclear ist meiner persönlichen Meinung nach einfach nicht erforderlich. Unerfahrene Unraider preclearen, formatieren innerhalb Unassigned Devices und stecken die bereits formatierte Platte ins Array. Tja, und dann kommen Nachfragen, die bei der Standardprozedur nicht erscheinen. Preclear nutze ich persönlich nur noch zum Löschen von gebrauchten Platten vor dem Verkauf. Ich gehe gleich z.B. in den Keller und schraube eine neue Platte rein. Aus der Verpackung nehmen und gem. den Schritten oben werde ich vorgehen. Wie immer. Bei ca. 200 Festplatten in den Jahren war nicht eine DOA. Unraid precleared selbst - sofern nicht vorher schon geschehen - aber die Schritte werden einfach komplizierter für Unerfahrene durch das Preclear vorab.

1.) Gab es schon vor Deiner Aktion eine Disk3? 2.) Guck mal auf die Platte mit "ls -l /mnt/disk3". Was kommt?

Falsche Reihenfolge - wenn es exakt in dieser Form ablief. Geclearte Festplatten werden vom Benutzer dem gestoppten Array hinzugefügt und dann erst durch Unraid (nicht Dich) formatiert (gem. Deiner Vorgabe - XFS, ...).

Das weiß ich nicht. Aber die Platte geht doch ohnehin nach der eingestellten Spin-Down Zeit (z.B. 15 Minuten) schlafen - sofern sie nicht weiter in Benutzung ist.

Blöde Frage: Geht das nicht mit einem kleinen Batch-Skript - hier Links? Sowohl Quellen und Ziele musst Du allerdings anpassen: C: CD \ MKDIR "Privat" MKLINK /D "C:\Privat\Backup" "\\192.168.178.35\disk17\Backup" MKLINK /D "C:\Privat\Bilder" "\\192.168.178.35\disk17\Bilder"

Nur zum Vergleich ein 18TB Data Rebuild auf alter lahmer Hardware (24 Disk, Dual Parity, TOSHIBA_MG09ACA18TE, TOSHIBA_HDWE160) :

Ist trotzdem falsch. Es ging im Quote, auf den Du geantwortet hast, um [...]Ordner auf dem Datenträger[...]. Jedes Root-Verzeichnis auf einem Datenträger ergibt einen Share. Nicht jedes Verzeichnis wie Du schriebst. Jetzt können wir es lassen.

Leichte Korrektur: Jedes gefundene Root-Verzeichnis. Ansonsten würde das zu viele Shares ergeben