Wenn SLES Btrfs schreibgeschützt wird: Diagnose vor dem erneuten Mounten

Wenn ein Btrfs-Dateisystem unter SUSE Linux Enterprise die Meldung „Schreibgeschütztes Dateisystem“ meldet, prüfen Sie zunächst, ob es absichtlich schreibgeschützt eingebunden wurde oder ob der Schreibschutz nach einem Fehler aktiviert wurde. Überprüfen Sie die Mount-Optionen, den freien Speicherplatz und das Kernel-Protokoll, bevor Sie versuchen, das Dateisystem erneut einzubinden. Verwenden Sie Snapper Rollback, um einen verifizierten, bootfähigen System-Snapshot zu erstellen. Falls Btrfs E/A- oder Metadatenfehler protokolliert hat, schützen Sie die Daten und analysieren Sie den Speicherpfad, bevor Sie erneut auf das Dateisystem schreiben.

1. Unterscheidung zwischen einer beabsichtigten schreibgeschützten Einbindung und einem Dateisystemfehler

Ersetzen Sie dies /datadurch den betroffenen Mountpunkt oder /durch root.

findmnt -T /data -o SOURCE,FSTYPE,OPTIONS
sudo btrfs filesystem show /data

Suchen Sie im ersten Befehl ronach rwden Optionen. Ein schreibgeschützter Snapper-Snapshot lehnt erwartungsgemäß Schreibvorgänge ab. Eine mit konfigurierte Einbindung rokann /etc/fstabebenfalls beabsichtigt sein. Btrfs kann nach schwerwiegenden Transaktions-, Metadaten- oder Gerätefehlern ebenfalls in den schreibgeschützten Modus wechseln. In diesem Fall behebt wiederholtes Ausführen mount -o remount,rwden Fehler nicht und kann sofort fehlschlagen.

Wenn das Dateisystem absichtlich schreibgeschützt eingebunden wurde, das Gerät fehlerfrei ist und das Kernel-Protokoll keine Btrfs- oder E/A-Fehler aufweist, kann eine normale Dateneinbindung im Lese-/Schreibmodus wiederhergestellt werden:

sudo mount -o remount,rw /data
findmnt -T /data -o TARGET,OPTIONS

Verwenden Sie diesen Befehl nicht zur Wiederherstellung eines gestarteten, schreibgeschützten Snapshots oder eines durch einen Fehler erzwungenen schreibgeschützten Dateisystems. Ein erfolgreiches Remount bestätigt die Schreibbarkeit, nicht die Integrität des Dateisystems.

2. Prüfen Sie, ob der Raumdruck das eigentliche Problem ist.

Btrfs kann unter Umständen nicht genügend Speicherplatz zur Verfügung haben, selbst wenn die einfache Festplattenansicht dies nicht vermuten lässt, da die Zuweisung von Daten und Metadaten getrennt verfolgt wird. Überprüfen Sie sowohl den normalen freien Speicherplatz als auch die Btrfs-Nutzung:

df -hT /data
sudo btrfs filesystem usage -T /data

Wenn das System Fehler meldet No space left on deviceund das Kernel-Protokoll keine Geräteausfälle oder Strukturfehler anzeigt, überprüfen Sie die Snapper-Nutzung, bevor Sie etwas entfernen:

sudo snapper list

Löschen Sie nur Snapshots, deren Verlust Ihre Aufbewahrungsrichtlinie sudo snapper delete SNAPSHOT_IDfür jede ausgewählte ID zulässt. Bewahren Sie einen bekannten, funktionierenden Snapshot vor dem Update auf, falls Sie eine Rollback-Option benötigen. Das Löschen von Snapshots gibt zwar Speicherplatz frei, entfernt aber Wiederherstellungspunkte. Die Bereinigung stellt möglicherweise nicht sofort Speicherplatz wieder her, und Snapshots beheben keine E/A-Fehler. Führen Sie keinen Speicherausgleich durch, um ein schreibgeschütztes Dateisystem beschreibbar zu machen. Dieser verschiebt Daten und ist für ein diagnostiziertes Zuordnungsproblem auf einem intakten, beschreibbaren Dateisystem vorgesehen.

3. Lesen Sie das Kernel-Protokoll, bevor Sie eine Reparaturmethode auswählen.

Achten Sie auf den ersten Btrfs-, Blockgeräte-, Controller- oder Transportfehler, nicht nur auf die abschließende Meldung, dass das Dateisystem schreibgeschützt wurde:

sudo journalctl -k -b --no-pager | grep -Ei 'btrfs|I/O error|nvme|ata|scsi'

Meldungen über fehlgeschlagene Lesevorgänge, Prüfsummenabweichungen, fehlende Geräte oder E/A-Fehler deuten auf eine andere Ursache als eine einfache roMount-Option hin. Überprüfen Sie die gemeldeten Informationen zum Zustand von Festplatte, Controller, RAID/HBA, SAN oder virtueller Festplatte sowie die Herstellerinformationen. Beheben Sie zunächst instabile Hardware oder Verbindungsprobleme. Wenn Daten wichtig sind, minimieren Sie Schreibvorgänge und erstellen Sie mit einem Administrator ein Backup oder ein Block-Level-Image, bevor Sie versuchen, das Dateisystem zu reparieren.

4. Wählen Sie die risikoärmste Wiederherstellungsmethode, die den vorliegenden Informationen entspricht.

Unter SLES verwenden bootfähige Snapshots die Standard-Root-Konfiguration von Snapper. Das Root-Volume muss auf einem Gerät im Btrfs-Format vorliegen, der Bootloader muss dies unterstützen, und es wird nur das Root-Subvolume zurückgesetzt. Überprüfen Sie einen Kandidaten vor dem Commit. Falls er ungeeignet ist, starten Sie das System neu und verwenden Sie eine Rettungsumgebung. Siehe die Rollback-Prozedur für Snapper unter SLES 15 SP7 .

Wann Offline-Prüfungen oder eine Bereinigung angebracht sind

Falls das Dateisystem nicht eingebunden werden kann oder Kernelmeldungen auf strukturelle Schäden hinweisen, starten Sie das SLES-Rettungssystem oder eine andere geeignete Wiederherstellungsumgebung, identifizieren Sie das richtige Gerät und stellen Sie sicher, dass es ausgehängt ist, bevor Sie die standardmäßige, schreibgeschützte Prüfung ausführen:

sudo btrfs check /dev/DEVICE

Verwenden Sie das eigentliche Btrfs-Blockgerät, nicht einen Mountpoint-Platzhalter. Eine Überprüfung kann Zeit und Speicherplatz beanspruchen und meldet strukturelle Probleme; sie garantiert keine Reparatur. Führen Sie diese Überprüfung nicht --repairroutinemäßig als nächsten Schritt durch. Die Btrfs-Dokumentation warnt davor, dass eine Reparatur die Situation verschlimmern kann und nur unter fachkundiger Anleitung und nach Akzeptanz des Datenrisikos erfolgen sollte. Wenden Sie sich an den SUSE-Support oder einen Btrfs-Spezialisten, wenn die Überprüfung Fehler meldet oder das Gerät E/A-Fehler aufweist.

Sobald der Speicher stabil ist und das Dateisystem mit Lese- und Schreibzugriff eingebunden wurde, sudo btrfs scrub start -B /datakönnen die Prüfsummen überprüft werden. Scrub ist kein Strukturprüfer. Es kann Schäden nur anhand einer bekannten, fehlerfreien redundanten Kopie beheben; bei einer Einzelkopie-Konfiguration erkennt es Fehler, kann aber verlorene Daten nicht wiederherstellen. Lesen Sie die Dokumentation zu Btrfs Scrub . Siehe auch den Dateisystemleitfaden von SUSE SLES 15 SP7 , den Artikel zur Btrfs-Wiederherstellung von SUSE und das Handbuch zu Btrfs Check .

Ergebnis überprüfen

Nach der gewählten Wiederherstellung prüfen Sie, ob das Mount die gewünschten Optionen bietet und einen sicheren Schreibvorgang durchführen kann:

findmnt -T /data -o TARGET,SOURCE,FSTYPE,OPTIONS
sudo touch /data/.rw-check && sudo rm /data/.rw-check

Um ein Root-Snapshot-Rollback durchzuführen, starten Sie das System zunächst neu und vergewissern Sie sich, dass es normal startet. Überprüfen Sie anschließend das neue Kernel-Log auf wiederkehrende Btrfs- oder Gerätefehler. Ein Lese-/Schreib-Flag allein ist kein Garant für einwandfreie Funktion: Treten Fehler erneut auf, stoppen Sie die Schreibvorgänge und kehren Sie zur Speicherdiagnose zurück.