January 10, 20233 yr Community Expert 4 hours ago, Sascha Heilemann said: Und dann versuche ich das zu machen was du vorschlägst. Was soll ich direkt danach tun? Wenn ich das Ganze richtig lese: Du hast nun einige Tage (und in der weiteren Vergangenheit auch noch Zeit) damit verballert das Array zum Laufen zu bekommen. Da bei unraid die Daten auf den Festplatten normal lesbar sind (ohne Array): Alle Daten, die Dir wichtig sind, extern sichern/Backuppen (3x4TB und 3x3TB = ca. 18TB Maximum (real ca. 16TB) = 1 Disk zu 18TB fuert aktuell unter 300 Euro). Dazu muß das Array nicht laufen. Die Arrayfestplatten kann man auch unter Linux auslesen und kopieren. Danach das Array komplett auflösen, alle Disks mit Preclear nullen/löschen, damit alle Datenträgerfehler gefunden werden. Wenn alle fehlerfrei durch laufen: Array beliebig wieder aufbauen und von dem Backup die Daten wieder zurück spielen. Das dürfte wohl schneller und nervenschonender gehen, als nun weitere Tage auf Fehlersuche zu ver(sch)wenden. Nicht billig (1mal Backupkapazität kaufen/leihen/zusammen kratzen), aber ein Backup der Daten, die einem wichtig sind, sollte man auch bei unraid mit Parity immer haben.
January 10, 20233 yr Author 1 hour ago, hawihoney said: Habe mittlerweile Deine PM bekommen, antworte aber hier. Wenn die Platten nicht verschlüsselt sind, dann muss das mit dem Parity Sync im Wartungsmodus zusammenhängen. Ich wusste nicht das das überhaupt geht ...? Bis da war ich noch nicht. Das Bild hätte mich jedenfalls zu Tode erschrocken. Das sieht ja aus als wäre alles auf allen Disks weg ... Warte einfach mal ab wie das ausgeht. Also ich es ist durchgelaufen es kam zu keinen wirklichen Fehler, Mounten ging wieder nicht, wollte dann versuchen mit UD mal auf die DISK 4 zu schauen aber er mountet diese auch nicht. Bei allen anderen platten kann ich was sehen auf den platten. Wie kann ich die Daten jetzt ohne Array starten downloaden? In UD hab ich nicht rausbekommen wie ich das hinbekomme. Finde es aber erstaunlich das man DISK 4 nicht MOUNten kann aber trotzdem er sie angeblich repariert ohne Fehler. Würde dann wirklich wie DataCollector meint alles was man speichern kann speichern. aber wie kann ich am besten die Daten runterladen vom Server. Kriege morgen noch nen Speicher würde aber jetzt schonmal mit anfangen das runter zuladen. Und das Protokoll von DISK4 Jan 10 18:22:18 Tower kernel: sd 5:0:0:0: [sdf] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB) Jan 10 18:22:18 Tower kernel: sd 5:0:0:0: [sdf] 4096-byte physical blocks Jan 10 18:22:18 Tower kernel: sd 5:0:0:0: [sdf] Write Protect is off Jan 10 18:22:18 Tower kernel: sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00 Jan 10 18:22:18 Tower kernel: sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jan 10 18:22:18 Tower kernel: sd 5:0:0:0: [sdf] Preferred minimum I/O size 4096 bytes Jan 10 18:22:18 Tower kernel: sdf: sdf1 Jan 10 18:22:18 Tower kernel: sd 5:0:0:0: [sdf] Attached SCSI disk Jan 10 18:22:46 Tower emhttpd: WDC_WD30EFAX-68JH4N1_WD-WX12D9102LTU (sdf) 512 5860533168 Jan 10 18:22:46 Tower kernel: mdcmd (5): import 4 sdf 64 2930266532 0 WDC_WD30EFAX-68JH4N1_WD-WX12D9102LTU Jan 10 18:22:46 Tower kernel: md: import disk4: (sdf) WDC_WD30EFAX-68JH4N1_WD-WX12D9102LTU size: 2930266532 Jan 10 18:22:46 Tower emhttpd: read SMART /dev/sdf Jan 10 18:23:20 Tower emhttpd: WDC_WD30EFAX-68JH4N1_WD-WX12D9102LTU (sdf) 512 5860533168 Jan 10 18:23:21 Tower kernel: mdcmd (5): import 4 sdf 64 2930266532 0 WDC_WD30EFAX-68JH4N1_WD-WX12D9102LTU Jan 10 18:23:21 Tower kernel: md: import disk4: (sdf) WDC_WD30EFAX-68JH4N1_WD-WX12D9102LTU size: 2930266532 Jan 10 18:23:21 Tower emhttpd: read SMART /dev/sdf Jan 10 18:23:46 Tower emhttpd: WDC_WD30EFAX-68JH4N1_WD-WX12D9102LTU (sdf) 512 5860533168 Jan 10 18:23:48 Tower emhttpd: read SMART /dev/sdf Jan 10 18:23:51 Tower unassigned.devices: Adding partition 'sdf1'... Jan 10 18:23:51 Tower unassigned.devices: Mounting partition 'sdf1' at mountpoint '/mnt/disks/WD-WX12D9102LTU'... Jan 10 18:23:51 Tower unassigned.devices: Mount drive command: /sbin/mount -t 'xfs' -o rw,noatime,nodiratime '/dev/sdf1' '/mnt/disks/WD-WX12D9102LTU' Jan 10 18:23:51 Tower kernel: XFS (sdf1): Mounting V5 Filesystem Jan 10 18:23:52 Tower kernel: XFS (sdf1): Starting recovery (logdev: internal) Jan 10 18:23:52 Tower kernel: XFS (sdf1): Corruption warning: Metadata has LSN (1:250434) ahead of current LSN (1:205846). Please unmount and run xfs_repair (>= v4.3) to resolve. Jan 10 18:23:52 Tower kernel: XFS (sdf1): Metadata corruption detected at xfs_agf_verify+0x64/0x1e2 [xfs], xfs_agf block 0x575428d9 Jan 10 18:23:52 Tower kernel: XFS (sdf1): Unmount and run xfs_repair Jan 10 18:23:52 Tower kernel: XFS (sdf1): First 128 bytes of corrupted metadata buffer: Jan 10 18:23:52 Tower kernel: XFS (sdf1): metadata I/O error in "xfs_read_agf+0xca/0x108 [xfs]" at daddr 0x575428d9 len 1 error 117 Jan 10 18:30:01 Tower unassigned.devices: Adding partition 'sdf1'... Jan 10 18:30:01 Tower unassigned.devices: Mounting partition 'sdf1' at mountpoint '/mnt/disks/WD-WX12D9102LTU'... Jan 10 18:30:01 Tower unassigned.devices: Mount drive command: /sbin/mount -t 'xfs' -o rw,noatime,nodiratime '/dev/sdf1' '/mnt/disks/WD-WX12D9102LTU' Jan 10 18:36:33 Tower unassigned.devices: Adding partition 'sdf1'... Jan 10 18:36:33 Tower unassigned.devices: Mounting partition 'sdf1' at mountpoint '/mnt/disks/WD-WX12D9102LTU'... Jan 10 18:36:33 Tower unassigned.devices: Mount drive command: /sbin/mount -t 'xfs' -o rw,noatime,nodiratime '/dev/sdf1' '/mnt/disks/WD-WX12D9102LTU' ** Press ANY KEY to close this window ** Edited January 10, 20233 yr by Sascha Heilemann
January 10, 20233 yr 7 minutes ago, Sascha Heilemann said: Jan 10 18:23:52 Tower kernel: XFS (sdf1): Corruption warning: Metadata has LSN (1:250434) ahead of current LSN (1:205846). Please unmount and run xfs_repair (>= v4.3) to resolve. Jan 10 18:23:52 Tower kernel: XFS (sdf1): Metadata corruption detected at xfs_agf_verify+0x64/0x1e2 [xfs], xfs_agf block 0x575428d9 Jan 10 18:23:52 Tower kernel: XFS (sdf1): Unmount and run xfs_repair Jan 10 18:23:52 Tower kernel: XFS (sdf1): First 128 bytes of corrupted metadata buffer: Jan 10 18:23:52 Tower kernel: XFS (sdf1): metadata I/O error in "xfs_read_agf+0xca/0x108 [xfs]" at daddr 0x575428d9 len 1 error 117 Und damit sind wir wieder beim oben von mir erwähnten xfs_repair. Du hast zwar geschrieben Du hättest das gemacht, ich sehe aber kein Protokoll von Dir. Was wurde durch den repair ausgegeben?
January 10, 20233 yr Author Just now, hawihoney said: Und damit sind wir wieder beim oben von mir erwähnten xfs_repair. Du hast zwar geschrieben Du hättest das gemacht, ich sehe aber kein Protokoll von Dir. Was wurde durch den repair ausgegeben? wie mache ich das was du vorschlägst, ich habe keine Ahnung wie das von dir beschriebene geht
January 10, 20233 yr 1 minute ago, Sascha Heilemann said: wie mache ich das was du vorschlägst, ich habe keine Ahnung wie das von dir beschriebene geht Hier die Theorie mit Examples: https://wiki.unraid.net/Check_Disk_Filesystems#xfs_repair Und hier die Praxis:
January 10, 20233 yr Author 3 minutes ago, hawihoney said: Hier die Theorie mit Examples: https://wiki.unraid.net/Check_Disk_Filesystems#xfs_repair Und hier die Praxis: brauchst du das? hawihonex xfs_repair -n.docx xfs-repair -nv.docx xfs_repair -L.docx xfs-repair -P.docx
January 10, 20233 yr Author 31 minutes ago, hawihoney said: Hier die Theorie mit Examples: https://wiki.unraid.net/Check_Disk_Filesystems#xfs_repair Und hier die Praxis: also es hat geklappt ich bin die Sachen wie im Video durchgegangen und er hat das array wieder gestartet. Vielen vielen lieben dank wie kann ich mich erkenntlich zeigen? Array läuft wieder Daten sehen gut aus erstmal muss diesen Lost Ordner jetzt nochmal durchschauen. lasse grade die Party Prüfung durchlaufen. Aber schonmal vielen lieben dank
January 10, 20233 yr 1 hour ago, Sascha Heilemann said: Lost Ordner Du wirst Datenverlust feststellen. Das war aber wohl lt. Repair Log nicht zu vermeiden. Und denk an Backup. Edited January 10, 20233 yr by hawihoney
February 17, 20233 yr Author Habt ihr eine Idee warum bei ParityCheck immer nur 4TB angezeigt werden und nicht der komplette Speicher von 18TB muss da wieder was umgestellt werden wegen der Reparatur im Abgesicherten Modus?
February 17, 20233 yr Author hier siehe bild er checkt scheinbar nur 4TB ab? was dann wahrscheinlich immer zu tausenden Fehlern führt
February 17, 20233 yr Ist ja auch richtig, deine Parity ist 4tb groß. Die Parity ist die Summe aller Daten in einem Sektor auf jeder Daten HDD. Deswegen kannst du ja quasi beliebig viele HDDs (und somit gigantische Mengen Nutzdaten) mit nur einer HDD absichern (zumindest gegen den Ausfall von einer HDD)
February 17, 20233 yr Author Bei der Prüfung standen früher aber 18TB und nicht 4TB! Bei so einer Prüfung erwarte ich das er ja alle Festplatten überprüft ob die alle Synchronisiert sind
February 17, 20233 yr Community Expert 1 minute ago, Sascha Heilemann said: Bei der Prüfung standen früher aber 18TB und nicht 4TB! Bei so einer Prüfung erwarte ich das er ja alle Festplatten überprüft ob die alle Synchronisiert sind Bei einem Array steht dort immer die Groesse der größten Paritätsdisk. Das habe ich seit unraid V.6.9.2 nie anders erlebt. Wen Du (jetzt) einen 4TB Paritätsdatenträger drin hast, wird er eben die 4TB testen. Wenn Du einen 18TB Paritätsdatenträger (vorher?) drin hattest, hat er vorher 18TB angezeigt. Ist ja auch logisch, da er nicht mitteilt, wieviele Daten er in Summe verglichen hat, sondern, daß er von Vorne (Position 0) bis Hinten (in diesem Fall 4TB) alle Datenträgersektoren mit den Paritätsquersummen verglichen hat.
February 17, 20233 yr Author Okay danke DataCollector dann hab ich da scheinbar nicht richtig aufgepasst
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.