Es handelt sich um ein ext4-Dateisystem auf einem mit LVM verwalteten logischen Volume mit LUKS-Verschlüsselung auf einem Hardware-RAID. Das Betriebssystem ist ein generisches Ubuntu 22.04 LTS.
Das RAID ist leider vor kurzem ausgefallen und das Dateisystem wurde zu diesem Zeitpunkt schreibgeschützt neu zugeordnet. Nachdem alle Anwendungen gestoppt wurden, die auf dieses Dateisystem schreiben, konnte das RAID mit etwas Glück vollständig wiederhergestellt werden. Und mit noch mehr Glück ist das Dateisystem mit den wiederhergestellten Daten immer noch vollständig lesbar! Und es e2fsckwurden nicht einmal Fehler gefunden.
Ist also alles in Ordnung? Leider nicht. Leider befinden sich noch immer ziemlich viele (Hunderte Megabyte) ungeschriebene Daten im Speicher und ich weiß nicht, wie ich diese auf die Festplatte bekomme. Deshalb habe ich noch nicht neu gestartet und möchte auch nicht neu starten, da die Reparatur aller Datenbankdateien mit diesen fehlenden Daten eine Menge Arbeit wäre. Das Vorhandensein der ungeschriebenen Daten kann einfach überprüft werden über:
sync ; grep Dirty /proc/meminfo
was normalerweise nur ein paar Kilobyte ergibt, in meinem Fall aber Hunderte von Megabyte. Leider weiß ich nicht, auf welcher Ebene der verschiedenen Kerneltreiber diese Daten herumhängen: im physischen Festplattencache, in einer der Datenträgergruppen oder im eigentlichen Dateisystem.
Bisherige Reparaturversuche
Mein erster Versuch bestand darin, das immer noch schreibgeschützte Dateisystem wie folgt erneut als Lese-/Schreibzugriff zu mounten:
mount -o remount /dev/mapper/vg1-data
Leider kommt dabei die Fehlermeldung:
mount: /data: cannot remount /dev/mapper/vg1-data read-write, is write-protected.
Für das tatsächliche Volume ist jedoch Lese-/Schreibzugriff möglich, wie folgendermaßen überprüft werden kann:
cat /sys/block/dm-*/ro
Dies gibt das Ergebnis 0für alles aus, was unter der Kontrolle des Geräte-Mappers steht, einschließlich der Volumes auf dem RAID. Dasselbe gilt für das eigentliche sdGerät selbst. Außerdem:
dmsetup info vg1-data
meldet den Status des Datenträgers als . Wenn der Datenträger schreibgeschützt wäre, ACTIVEwürde der Status stattdessen als gemeldet . Ebenso zeigt normale Attribute von an .ACTIVE (READ-ONLY)lvs-wi-ao----
Ein großer Hinweis, dass die Lese-/Schreibfähigkeit des Dateisystems tatsächlich NICHT die Ursache des Problems ist, ist über verfügbar tune2fs -l. Dies druckt neben vielen anderen Statistiken diese Informationen über den letzten Fehler im gemounteten Dateisystem aus:
Last error time: Wed Jan 17 18:47:43 2024
Last error function: ext4_remount
Last error line #: 5822
Last error err: EBUSY
Zum Zeitpunkt des Fehlers wurde diese kryptische Zeile in das Syslog geschrieben:
EXT4-fs error (device dm-N): ext4_remount:5822: comm mount: Abort forced by user
Wenn ich den Datenträger explizit in den schreibgeschützten Modus zwinge über:
dmsetup table vg1-data | dmsetup reload -r vg1-data
dmsetup resume vg1-data
dmsetup info vg1-data
weitere mountVersuche aktualisieren den Zeitstempel „Zeit des letzten Fehlers“ dann NICHT mehr, sondern führen zu derselben (und nun offensichtlich korrekten) Fehlermeldung. Nachdem ich dmsetuperneut versucht habe, das Volume lesbar und beschreibbar zu machen, mountaktualisieren weitere Versuche den Zeitstempel des letzten Fehlers erneut und schreiben auch wieder ins Syslog.
In einem anderen Serverfault-Beitrag fand ich den Hinweis, die Disk-Mapper-Volumes auf schreibgeschützt und dann wieder auf Lese-/Schreibzugriff zu setzen, aber auch das funktionierte nicht:Linux-Software-RAID 1 - Root-Dateisystem wird nach einem Fehler auf einer Festplatte schreibgeschützt
cryptsetup reloadauch nichts gebracht.