050
19.09.2026, 14:02 Uhr
MarioG77
|
Hab mal meinen copilot gefragt...
| Zitat: |
Die Fehler sehen für mich erst einmal nicht nach einem aktuellen Plattendefekt, sondern nach einer schon seit Jahren bestehenden Inkonsistenz in den Btrfs-Metadaten aus.
Die entscheidenden Meldungen sind immer diese:
root 256 inode 1975637 errors 2001, no inode item, link count wrong
unresolved ref dir 35315 ... name 2018jul-Mondfinsternis ... no inode ref
Das bedeutet vereinfacht:
In einem Verzeichnis existiert noch ein Eintrag (2018jul-Mondfinsternis).
Die zugehörige Inode existiert aber nicht mehr.
Das ist ein "dangling directory entry".
Die Verzeichnisstruktur verweist auf Dateien oder Unterverzeichnisse, deren Metadaten verloren gegangen sind.
Das ist bereits vor 3 Jahren aufgetreten:
2018jul-Mondfinsternis
2021nov-ende-gartenstübl
DSCN0667.JPG
HP-Netserver
Fotos
...
Und heute tauchen dieselben Fehlertypen wieder auf:
no inode item
link count wrong
unresolved ref
no inode ref
Allerdings mit anderen Dateien.
Was mir dabei auffällt
Vor 3 Jahren:
found 1385843367936 bytes used
Heute:
found 2366610944000 bytes used
Das Dateisystem wurde also trotz bekannter Fehler jahrelang weiter benutzt und beschrieben.
Wenn damals kein Repair durchgeführt wurde, ist es durchaus möglich, dass:
einzelne beschädigte Metadatenbäume weitergewachsen sind,
neue Dateien in bereits inkonsistenten Verzeichnissen angelegt wurden,
heute deutlich mehr Verzeichniseinträge betroffen sind.
Das wichtigste zuerst
Ich würde als allererstes prüfen:
btrfs scrub status /mountpunkt
bzw.
btrfs device stats /mountpunkt
Interessant sind Werte wie:
write_io_errs
read_io_errs
flush_io_errs
corruption_errs
generation_errs
Wenn dort überall 0 steht, spricht das tatsächlich eher gegen einen aktuellen Hardwarefehler.
Zusätzlich:
smartctl -a /dev/sdX
insbesondere:
Current_Pending_Sector
Reallocated_Sector_Ct
Offline_Uncorrectable
UDMA_CRC_Error_Count
Nur weil dd durchläuft, ist die Platte nämlich noch nicht automatisch gesund.
Was ich NICHT tun würde
Auf keinen Fall blind:
btrfs check --repair
laufen lassen.
Das Btrfs-Team warnt seit Jahren davor, --repair nur als allerletzte Maßnahme einzusetzen.
Es gab schon genügend Fälle, wo ein ursprünglich noch mountbares Dateisystem danach deutlich schlechter dastand.
Sinnvolle Bestandsaufnahme
Zunächst:
mount | grep btrfs
und:
btrfs filesystem show
btrfs filesystem usage /mountpunkt
Dann:
dmesg | grep -i btrfs
journalctl -k | grep -i btrfs
Oft findet man dort Hinweise wie:
parent transid verify failed
csum error
tree block corruption
Das wäre deutlich aussagekräftiger als die btrfs check-Ausgabe.
Wenn Verzeichnisse bereits verschwunden sind
Dann würde ich zunächst versuchen festzustellen, ob die Daten wirklich weg sind oder nur der Verzeichniseintrag.
Beispielsweise:
btrfs restore -vi /dev/sdX /mnt/rettung
btrfs restore arbeitet direkt auf dem Blockgerät und ignoriert viele Metadatenfehler.
Erstaunlich oft bekommt man damit noch Dateien heraus, die im regulären Mount nicht mehr sichtbar sind.
Meine Vermutung
Da:
die gleichen Fehlertypen bereits vor 3 Jahren vorhanden waren,
sich die Fehleranzahl offenbar über die Jahre verändert hat,
ein Image mit dd lesbar ist,
würde ich aktuell auf eine der folgenden Ursachen tippen:
Historische Btrfs-Metadatenkorruption, die nie repariert wurde.
Früherer RAM-Fehler oder Absturz während eines Schreibvorgangs.
Controller-/Kabelproblem in der Vergangenheit.
Fehlerhafte Abschaltungen oder Stromausfälle.
Weniger wahrscheinlich: aktueller HDD-Defekt.
Ich würde daher jetzt zuerst ein vollständiges Image sichern, solange die Platte noch vollständig lesbar ist:
ddrescue -f /dev/sdX /backup/platte.img /backup/platte.log
Danach kann man wesentlich entspannter weitere Analysen durchführen.
Interessant wären jetzt noch die Ausgaben von:
btrfs filesystem show
btrfs device stats /mountpunkt
smartctl -a /dev/sdX
dmesg | grep -i btrfs | tail -100
Vor allem die device stats und die Kernel-Meldungen geben meist sehr schnell Aufschluss darüber, ob wir auf einen echten Datenträgerfehler oder eher auf alte Metadatenkorruption schauen.
|
Und nach Verweis auf den kompletten Thread:
| Zitat: |
Ich habe mir den Thread angesehen. Das Interessante ist, dass die ursprünglichen Probleme bereits im Oktober 2023 aufgetreten sind, als Enrico nach einem größeren Kopiervorgang plötzlich nicht mehr auf bestimmte Verzeichnisse zugreifen konnte und I/O-Fehler erhielt. Die SMART-Werte waren damals bereits unauffällig.
Was mich an deiner aktuellen Beschreibung stutzig macht:
Die btrfs check-Fehler von damals und heute sind praktisch identisch.
Es handelt sich immer um:
no inode item
no inode ref
unresolved ref
link count wrong
Die betroffenen Dateien ändern sich, das Fehlermuster aber nicht.
Für mich sieht das nach einer langfristig fortschreitenden Metadatenkorruption aus, nicht nach einem akuten HDD-Defekt.
Die Theorie im Forum, dass Btrfs Inodes außerhalb des Datenträgers vergeben hätte, halte ich ehrlich gesagt für sehr unwahrscheinlich. Btrfs hat keine klassische feste Inode-Tabelle wie ext2/ext3/ext4. Die Fehlermeldungen deuten vielmehr darauf hin, dass Verzeichniseinträge auf Objekte zeigen, deren Inode-Metadaten im B-Tree fehlen.
Das würde auch erklären:
Verzeichnisse verschwinden.
Dateien sind teilweise noch vorhanden, aber nicht mehr erreichbar.
Beim Kopieren erscheinen Quelle und Ziel unterschiedlich.
Die Fehler nehmen über Jahre langsam zu.
Meine Vermutung wäre eher eine dieser Ursachen:
Frühere RAM-Probleme (ohne ECC).
Ein Fehler im SATA-Controller oder Kabel.
Stromausfall bzw. Absturz während intensiver Schreiblast.
Bereits beschädigtes Dateisystem, das seit Jahren weiter genutzt wird.
Dass ein dd-Image vollständig durchläuft, spricht zumindest dafür, dass die Platte aktuell noch lesbar ist. Es sagt aber nichts darüber aus, ob die Metadaten konsistent sind.
Wenn das mein System wäre, würde ich jetzt in dieser Reihenfolge vorgehen:
smartctl -a /dev/sdX
btrfs device stats /mnt/btrfs
btrfs scrub status /mnt/btrfs
und insbesondere die Kernelmeldungen prüfen:
journalctl -k | grep -i btrfs
bzw.
dmesg | grep -i btrfs
Falls die Daten wichtig sind:
Vollständiges Image sichern.
Möglichst viele Daten mit rsync oder btrfs restore herunterkopieren.
Dateisystem neu anlegen.
Daten zurückspielen.
btrfs check --repair wäre für mich erst die allerletzte Option, wenn ein Backup existiert und eine Neuinstallation ohnehin droht.
Der Umstand, dass dieselbe Art von Fehlern bereits vor 3 Jahren dokumentiert wurde und heute wieder auftaucht, spricht für mich übrigens stark dagegen, dass die aktuelle Ursache ein plötzlich aufgetretener Defekt der Festplatte ist. Viel wahrscheinlicher ist, dass das Dateisystem seit 2023 inkonsistent war und die Korruption langsam weitergewandert ist.
|
Vielleicht hilft dir das weiter...
--
Gruss Mario
Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben
Dieser Beitrag wurde am 19.09.2026 um 14:03 Uhr von MarioG77 editiert. |
ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
