Als SLES Btrfs alleen-lezen wordt: diagnose stellen vóór het opnieuw mounten

Als een SUSE Linux Enterprise Btrfs-bestandssysteem de melding "Alleen-lezen bestandssysteem" geeft, controleer dan eerst of het opzettelijk als alleen-lezen is aangekoppeld of dat dit na een fout is gebeurd. Controleer de aankoppelopties, de vrije ruimte en het kernel-logboek voordat u een heraankoppeling probeert. Gebruik Snapper rollback voor een geverifieerde opstartbare systeemsnapshot; als Btrfs I/O- of metadatafouten heeft geregistreerd, bescherm dan de gegevens en analyseer het opslagpad voordat u opnieuw naar het bestandssysteem schrijft.

1. Een opzettelijke alleen-lezen-mount onderscheiden van een bestandssysteemfout

Vervang dit /datadoor het betreffende mountpoint, of /voor root.

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

Zoek in de eerste opdracht naar roof rwin de opties. Een alleen-lezen Snapper-snapshot zal naar verwachting schrijfbewerkingen weigeren. Een mount die geconfigureerd is met roin /etc/fstabkan ook opzettelijk zijn. Btrfs kan ook overschakelen naar alleen-lezen na ernstige transactie-, metadata- of apparaatfouten. In dat geval lost het herhaaldelijk uitvoeren van mount -o remount,rwde opdracht de oorzaak niet op en kan de opdracht direct mislukken.

Als het bestandssysteem opzettelijk alleen-lezen is aangekoppeld, het apparaat in goede staat verkeert en het kernel-logboek geen Btrfs- of I/O-fouten bevat, kan een normale data-aankoppeling opnieuw worden aangekoppeld met lees-schrijfrechten:

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

Gebruik dit niet als herstelopdracht voor een opgestarte, alleen-lezen snapshot of een door een fout geforceerd, alleen-lezen bestandssysteem. Een succesvolle herkoppeling bevestigt de beschrijfbaarheid, niet de integriteit van het bestandssysteem.

2. Controleer of de ruimtedruk daadwerkelijk het probleem is.

Btrfs kan een tekort aan toewijsbare ruimte hebben, zelfs als een standaard schijfweergave er verrassend uitziet, omdat de toewijzing van data en metadata afzonderlijk wordt bijgehouden. Controleer zowel de gewone vrije ruimte als het Btrfs-gebruik:

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

Als het systeem No space left on deviceen het kernel-logboek geen apparaatfouten of structurele fouten tonen, controleer dan het Snapper-gebruik voordat u iets verwijdert:

sudo snapper list

Verwijder alleen snapshots die volgens uw bewaarbeleid verwijderd mogen worden, en gebruik hiervoor de optie sudo snapper delete SNAPSHOT_IDvoor elke geselecteerde ID. Bewaar een bekende, goede snapshot van vóór de update als u een terugdraaioptie nodig hebt; het verwijderen van snapshots maakt ruimte vrij, maar verwijdert herstelpunten. Opschonen levert mogelijk niet direct ruimte op en snapshots lossen geen I/O-fouten op. Voer geen balancering uit om een ​​alleen-lezen bestandssysteem beschrijfbaar te maken; dit verplaatst gegevens en is bedoeld voor een vastgesteld toewijzingsprobleem op een gezond, beschrijfbaar bestandssysteem.

3. Lees het kernel-logboek voordat u een reparatie kiest.

Zoek naar de eerste Btrfs-, block-device-, controller- of transportfout, niet alleen naar het laatste bericht dat het bestandssysteem alleen-lezen is geworden:

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

Berichten over mislukte leesbewerkingen, checksum-mismatches, ontbrekende apparaten of I/O-fouten wijzen op een andere aanpak dan een simpele romount-optie. Controleer de gerapporteerde informatie over de schijf, controller, RAID/HBA, SAN- of virtuele-schijflaag en de status van de leverancier. Los eerst instabiele hardware- of verbindingsproblemen op. Als data belangrijk is, minimaliseer dan schrijfbewerkingen en maak een back-up of een image op blokniveau met een beheerder voordat u probeert het bestandssysteem te herstellen.

4. Kies het minst risicovolle herstel dat overeenkomt met het bewijsmateriaal.

Op SLES gebruiken opstartbare snapshots de standaard Snapper-rootconfiguratie. De root moet Btrfs zijn op één apparaat, de bootloader moet dit ondersteunen en alleen het root-subvolume wordt teruggezet. Controleer een kandidaat voordat u de wijzigingen doorvoert; als deze ongeschikt is, start u het systeem opnieuw op of start u het herstelproces. Zie de Snapper-terugzetprocedure voor SLES 15 SP7 .

Wanneer offline controles of een grondige controle nodig zijn

Als het bestandssysteem niet kan worden aangekoppeld of als kernelberichten wijzen op structurele schade, start dan het SLES-herstelsysteem of een andere geschikte herstelomgeving op, identificeer het juiste apparaat en zorg ervoor dat het is ontkoppeld voordat u de standaard, alleen-lezen controle uitvoert:

sudo btrfs check /dev/DEVICE

Gebruik het daadwerkelijke Btrfs-blokapparaat, niet een placeholder voor een mountpoint. Een controle kan tijd en geheugen in beslag nemen en rapporteert structurele bevindingen; het garandeert geen reparatie. Voeg dit niet toe --repairals een standaard vervolgstap. De Btrfs-documentatie waarschuwt dat reparatie de situatie kan verergeren en alleen onder begeleiding van een expert mag worden uitgevoerd, nadat het datarisico is geaccepteerd. Raadpleeg SUSE-ondersteuning of een Btrfs-specialist wanneer de controle fouten rapporteert of het apparaat I/O-fouten vertoont.

Nadat de opslag stabiel is en het bestandssysteem lees-schrijfbaar is aangekoppeld, sudo btrfs scrub start -B /datakunnen de checksums worden gecontroleerd. Scrub is geen structurele controle. Het kan schade alleen herstellen vanuit een bekende, goede redundante kopie; bij een lay-out met één kopie detecteert het fouten, maar kan het verloren gegevens niet reconstrueren. Lees de Btrfs scrub-documentatie . Zie ook de SUSE SLES 15 SP7-bestandssysteemhandleiding , het SUSE-artikel over Btrfs-herstel en de Btrfs check-handleiding .

Controleer het resultaat

Controleer na het gekozen herstelproces of de mount de gewenste opties heeft en veilig kan schrijven:

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

Voor een terugdraaiing van een root snapshot moet u eerst het systeem opnieuw opstarten en controleren of het standaardsysteem normaal opstart. Controleer vervolgens het nieuwe kernel-logboek op terugkerende Btrfs- of apparaatfouten. Een lees-schrijfvlag alleen is geen garantie voor een goede werking: als de fouten zich herhalen, stop dan met schrijven en ga terug naar de opslagdiagnose.