ich betreibe eine Debian Linux Kiste, mitunter als NAS. Hierfür stecken zwei Seagate Barracuda 4TB (ja, SMR, ich weiß, CMR wäre besser...) in einem mdadm raid1, ext4 formatiert und freigegeben via SMB und NFS.
Das ganze läuft seit rund 15 Jahren (früher noch mit ext3) mit immer wieder Hardware-Upgrades (beginnend bei 2x80GB, mittlerweile bei 2x4TB) eigentlich ohne Probleme. Hatte wirklich nie Probleme. Okay, mal eine verreckte IBM Platte vor etlichen Jahren. Aber war nie ein Problem. Platte getauscht, Raid wieder gesynct, fertig.
Seit einigen Wochen ärgert mich das System aber durchgehend:
Das RAID hatte eine Platte aus dem Verbund wegen eines Fehler entfernt. Ganz verstanden wieso das passiert ist habe ich nicht. Ich hab die Platte mit smartctl etc. getestet, auch im long-test. Keine Fehler. Also Platte erstmal wieder in den RAID Verbund aufgenommen, gesynct, fertig. Läuft wieder.... unter Beobachtung...
Mittlerweile habe ich aber mindestens ein Verzeichnis im Dateisystem des RAIDs das sich nicht löschen lässt. Fehlermeldung:
Code: Alles auswählen
rm: das Entfernen von 'zm/events/16/2021-09-16/85178/00059-capture.jpg' ist nicht möglich: Die Struktur muss bereinigt werden
Riecht für mich nach einem Fehler den ich mit e2fsck beheben kann... Pustekuchen. Das findet zwar was, und scheint das auch zu beheben, ändert aber nix an der Tatsache dass ich es mit besagter Fehlermeldung nicht löschen kann.
Gut, dachte ich, mach ich ein Komplett-Backup des 4TB RAID1 auf eine baugleiche weitere 4TB Platte, formatiere das RAUD und schiebe alles zurück. Also rsync angestoßen... Aber auch nach über 10h waren die belegten knapp 2TB noch nicht fertig kopiert. Nicht mal Ansatzweise.
dmesg sagt während dessen primär folgendes:
Code: Alles auswählen
[1183591.219402] EXT4-fs error (device md127): ext4_lookup:1706: inode #158597652: comm e4defrag: iget: bad extra_isize 28338 (inode size 256)
[1183611.609795] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602992: comm rm: iget: bad extra_isize 28338 (inode size 256)
[1183611.675527] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602986: comm rm: iget: bad extra_isize 28338 (inode size 256)
[1183611.700775] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602888: comm rm: iget: bad extra_isize 28338 (inode size 256)
[1183611.735658] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602894: comm rm: iget: bad extra_isize 28338 (inode size 256)
[1183611.774888] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602983: comm rm: iget: bad extra_isize 9234 (inode size 256)
[1183611.800263] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602956: comm rm: iget: bad extra_isize 28338 (inode size 256)
[1183611.833437] EXT4-fs error (device md127): ext4_lookup:1706: inode #158603004: comm rm: iget: bad extra_isize 28338 (inode size 256)
[1183611.874344] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602927: comm rm: iget: bad extra_isize 9234 (inode size 256)
Was ich nicht verstehe:
Wenn smartctl für beide Platten im RAID Verbund keine Fehler im long-test findet, und e2fsck erstmal alle Fehler behebt: Wie kann es dann noch Fehler geben? Und was ist die Ursache?
Jetzt werden viele "Backup hilft" schreien....
Ja, das ist so ne Sache. Wie viele Backups eines 4TB Systems, von dem etwas über 2TB belegt sind passen auf eine 4TB Backup-Platte?
Ich hab auch nicht die Ressourcen um mehrere Backups abzulegen. D.h. eines muss erstmal reichen.
Nun zurück zum Problem: Wenn doch hinter dem ext4 Dateisystem ein RAID1 steckt und beide Platten keinen smartctl erkennbaren Defekt haben: Sollte sich da das Dateisystem nicht reparieren lassen?
Was ist die Ursache für die Fehler die dmesg ausspuckt. Google sagt dazu: Platte/Hardware defekt. Andere Tools sagen: Alles gut.
Ja was denn nun? Hat einer einen Tipp für mich?
Gruß
Alex