mani3321 Posted April 24, 2021 Share Posted April 24, 2021 (edited) Hat jemand eine Idee, wie ich erfahre welche Files betroffen sind? In den Logs steht nur der Sektor etc. aber nichts über bzgl. Filenamen... Edited April 24, 2021 by mani3321 Quote Link to comment
mgutt Posted April 24, 2021 Share Posted April 24, 2021 In so einem Fall sollte man die Disk ersetzen und den Inhalt der Disk über die Parität oder aus einem Backup wiederherstellen. Das sind ja schließlich nur die Fehler, die beim Zugriff weniger Sektoren resultierten. Es kann durchaus sein, dass es viel mehr sind, die erst erkannt werden, wenn auf andere Bereiche der HDD zugegriffen wird. Kommt aber auch auf die Fehlermeldungen an. Vielleicht ist auch nur die Verbindung zur HDD fehlerhaft?! Wenn du es trotzdem herausfinden willst: https://forums.unraid.net/topic/74635-solved-determine-file-used-by-sector-in-xfs/?tab=comments#comment-687688 Quote Link to comment
mani3321 Posted April 24, 2021 Author Share Posted April 24, 2021 (edited) 17 minutes ago, mgutt said: In so einem Fall sollte man die Disk ersetzen und den Inhalt der Disk über die Parität oder aus einem Backup wiederherstellen. Das sind ja schließlich nur die Fehler, die beim Zugriff weniger Sektoren resultierten. Es kann durchaus sein, dass es viel mehr sind, die erst erkannt werden, wenn auf andere Bereiche der HDD zugegriffen wird. Kommt aber auch auf die Fehlermeldungen an. Vielleicht ist auch nur die Verbindung zur HDD fehlerhaft?! Wenn du es trotzdem herausfinden willst: https://forums.unraid.net/topic/74635-solved-determine-file-used-by-sector-in-xfs/?tab=comments#comment-687688 Parität wird leider schwer, gleiches gilt für Backup... (initiales backup lief gerade... bzw. Parität wird schwer nachdem das ganze nach dem update auf 6.9.x auftrat => Webpage ssh etc. war leider nicht mehr erreichbar. kurz ich musste das System abwürgen...) Deshalb die Frage wie man die betroffenen files erkennt..... log beinhaltet nur Apr 13 09:07:15 Tower kernel: md: disk6 read error, sector=3776186344 Apr 13 09:07:15 Tower kernel: md: disk6 read error, sector=3776186352 Apr 13 09:07:15 Tower kernel: md: disk6 read error, sector=3776186360 Apr 13 09:07:15 Tower kernel: ata12: EH complete Apr 13 09:07:15 Tower kernel: md: recovery thread: multiple disk errors, sector=3776186344 Apr 13 09:07:15 Tower kernel: md: recovery thread: multiple disk errors, sector=3776186352 Apr 13 09:07:15 Tower kernel: md: recovery thread: multiple disk errors, sector=3776186360 ..... Verbindung denke ich nicht (nach erfolgreichen btrfs scrub, sowie Parity-Check passierte) Edited April 24, 2021 by mani3321 Quote Link to comment
mgutt Posted April 24, 2021 Share Posted April 24, 2021 Zeigt die Platte CRC Fehler? Vielleicht es ja nur ein Verbindungsproblem. Poste mal die SMART-Daten der Platte. Außerdem die Frage ob XFS oder BTRFS. Mein Link bezieht sich auf XFS. 4 minutes ago, mani3321 said: log beinhaltet nur Check auch mal die Systemlogs in dem Zeitraum. Vielleicht gibt es noch allgemeine ATA Fehler. Solche Fehler können meine ich auch entstehen, wenn der RAM defekt ist. Sollte man auch prüfen. Quote Link to comment
mani3321 Posted April 24, 2021 Author Share Posted April 24, 2021 3 minutes ago, mgutt said: Zeigt die Platte CRC Fehler? Vielleicht es ja nur ein Verbindungsproblem. Poste mal die SMART-Daten der Platte. Außerdem die Frage ob XFS oder BTRFS. Mein Link bezieht sich auf XFS. Check auch mal die Systemlogs in dem Zeitraum. Vielleicht gibt es noch allgemeine ATA Fehler. BTRFS und keine ATA Fehler Quote Link to comment
mgutt Posted April 24, 2021 Share Posted April 24, 2021 36 minutes ago, mani3321 said: Webpage ssh etc. war leider nicht mehr erreichbar. kurz ich musste das System abwürgen... 28 minutes ago, mani3321 said: BTRFS BTRFS mag es gar nicht, wenn das System hart abschaltet. Vor einem Array-Start sollte man daher immer erst einen Scrub machen, falls es dazu gekommen ist. Das solltest du jetzt auch machen: https://wiki.archlinux.org/index.php/Identify_damaged_files#btrfs Die Platte zeigt Fehler wie den "Offline Uncorrectable". Da es aber keinen "Reallocated Sector Count" und keinen "Current Pending Sector" gibt, scheint es kein physisches Problem zu sein. Am besten nach dem Scrub mal einen langen SMART Test machen. Quote Link to comment
mani3321 Posted April 24, 2021 Author Share Posted April 24, 2021 3 minutes ago, mgutt said: HAttest du BTRFS mag es gar nicht, wenn das System hart abschaltet. Vor einem Array-Start sollte man daher immer erst einen Scrub machen, falls es dazu gekommen ist. Das solltest du jetzt auch machen: https://wiki.archlinux.org/index.php/Identify_damaged_files#btrfs Die Platte zeigt Fehler wie den "Offline Uncorrectable". Da es aber keinen "Reallocated Sector Count" und keinen "Current Pending Sector" gibt, scheint es kein physisches Problem zu sein. Am besten nach dem Scrub mal einen langen SMART Test machen. Danke für info ich werde später die Ergebnisse posten... PS: was meintest du mit "HAttest du" ? Quote Link to comment
mgutt Posted April 24, 2021 Share Posted April 24, 2021 2 minutes ago, mani3321 said: HAttest du Keine Ahnung. Hab's gelöscht ^^ Quote Link to comment
mani3321 Posted April 24, 2021 Author Share Posted April 24, 2021 11 minutes ago, mgutt said: BTRFS mag es gar nicht, wenn das System hart abschaltet. Vor einem Array-Start sollte man daher immer erst einen Scrub machen, falls es dazu gekommen ist. Das solltest du jetzt auch machen: https://wiki.archlinux.org/index.php/Identify_damaged_files#btrfs btrfs scrub status führte zu keinen Fehler. (Ich hätte das als Widerspruch zu dem "gui report" gesehen... ) Eventuell hilft die info Quote Link to comment
Recommended Posts
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.