Când SLES Btrfs devine doar pentru citire: Diagnosticare înainte de remontare

Dacă un sistem de fișiere SUSE Linux Enterprise Btrfs raportează „Sistem de fișiere doar în citire”, aflați mai întâi dacă a fost montat intenționat doar în citire sau a fost comutat la doar citire după o eroare. Verificați opțiunile de montare, spațiul liber și jurnalul kernelului înainte de a încerca o remontare. Utilizați rollback-ul Snapper pentru o instantanee a sistemului bootabil verificată; dacă Btrfs a înregistrat erori de I/O sau de metadate, protejați datele și diagnosticați calea de stocare înainte de a scrie din nou în sistemul de fișiere.

1. Identificați o montare intenționată doar în citire dintr-o eroare de sistem de fișiere

Înlocuiți /datacu punctul de montare afectat sau /pentru root.

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

În prima comandă, căutați rosau rwîn opțiuni. Se așteaptă ca o instantanee Snapper doar pentru citire să respingă scrierile. O montare configurată cu roin /etc/fstabpoate fi, de asemenea, intenționată. Btrfs poate trece, de asemenea, la doar citire după erori grave de tranzacție, metadate sau dispozitiv. În acest caz, rularea repetată mount -o remount,rwnu repară cauza și poate eșua imediat.

Dacă sistemul de fișiere a fost montat în mod deliberat în modul read-only, dispozitivul său este sănătos și jurnalul kernelului nu are erori Btrfs sau I/O, o montare normală de date poate fi remontată în modul read-write:

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

Nu folosiți aceasta ca o comandă de recuperare pentru o instantanee read-only pornită sau pentru un sistem de fișiere read-only forțat din cauza unei erori. O remontare reușită confirmă posibilitatea de scriere, nu integritatea sistemului de fișiere.

2. Verificați dacă presiunea spațiului este problema reală

Btrfs poate rămâne fără spațiu alocat chiar și atunci când o vizualizare de bază a discului pare surprinzătoare, deoarece alocarea datelor și a metadatelor este urmărită separat. Verificați atât spațiul liber obișnuit, cât și utilizarea Btrfs:

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

Dacă sistemul raportează acest lucru No space left on deviceși jurnalul kernelului nu arată erori ale dispozitivului sau erori structurale, verificați utilizarea Snapper înainte de a elimina orice:

sudo snapper list

Ștergeți doar instantaneele pe care politica dvs. de retenție vă permite să le pierdeți, utilizând sudo snapper delete SNAPSHOT_IDpentru fiecare ID selectat. Păstrați un instantaneu pre-actualizare cunoscut ca fiind valid dacă aveți nevoie de o opțiune de revenire la starea inițială; ștergerea instantaneelor ​​recuperează spațiu, dar elimină punctele de recuperare. Curățarea poate să nu returneze spațiu imediat, iar instantaneele nu vor remedia erorile I/O. Nu executați o echilibrare pentru a forța un sistem de fișiere doar pentru citire ca fiind inscriptibil; aceasta mută date și este destinată unei probleme de alocare diagnosticate pe un sistem de fișiere sănătos, inscriptibil.

3. Citiți jurnalul kernelului înainte de a alege o reparație

Căutați prima eroare Btrfs, block-device, controller sau transport, nu doar mesajul final care indică faptul că sistemul de fișiere a devenit read-only:

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

Mesajele despre citiri eșuate, neconcordanțe de sumă de control, dispozitive lipsă sau erori I/O indică o cale diferită de o simplă roopțiune de montare. Verificați informațiile despre discul, controlerul, RAID/HBA, SAN sau stratul de disc virtual și starea furnizorului raportate. Corectați mai întâi hardware-ul sau conectivitatea instabilă. Dacă datele sunt importante, reduceți la minimum scrierile și aranjați o copie de rezervă sau o imagine la nivel de bloc cu un administrator înainte de a încerca repararea sistemului de fișiere.

4. Alegeți recuperarea cu cel mai puțin risc care corespunde dovezilor

Pe SLES, snapshot-urile bootabile utilizează configurația implicită a rădăcinii Snapper. Rădăcina trebuie să fie Btrfs pe un dispozitiv, încărcătorul de boot trebuie să îl accepte și doar subvolumul rădăcină este anulat. Verificați un candidat înainte de validare; dacă este nepotrivit, reporniți sistemul la sistemul curent sau la mediul de salvare. Consultați procedura de anulare a anulării la SLES 15 SP7 Snapper .

Când sunt potrivite verificările offline sau o verificare preliminară

Dacă sistemul de fișiere nu se montează sau mesajele kernelului sugerează deteriorări structurale, porniți sistemul de salvare SLES sau alt mediu de recuperare adecvat, identificați dispozitivul corect și asigurați-vă că este demontat înainte de a rula verificarea implicită, doar pentru citire:

sudo btrfs check /dev/DEVICE

Folosește dispozitivul bloc Btrfs propriu-zis, nu un substituent pentru punctul de montare. O verificare poate necesita timp și memorie și raportează constatări structurale; nu garantează repararea. Nu adăugați --repairurmătorul pas ca o rutină. Documentația Btrfs avertizează că repararea poate agrava situația și trebuie utilizată numai cu îndrumarea unui expert după acceptarea riscului legat de date. Consultați asistența SUSE sau un specialist Btrfs atunci când verificarea raportează erori sau dispozitivul are erori I/O.

După ce stocarea este stabilă și sistemul de fișiere este montat în citire-scriere, sudo btrfs scrub start -B /datapoate verifica sumele de control. Scrub nu este un verificator structural. Poate repara daunele doar dintr-o copie redundantă cunoscută ca fiind bună; pe un layout cu o singură copie, detectează erori, dar nu poate reconstrui datele pierdute. Citiți documentația Btrfs scrub . Consultați și ghidul sistemelor de fișiere SLES 15 SP7 de la SUSE , articolul despre recuperarea Btrfs de la SUSE și manualul de verificare Btrfs .

Verificați rezultatul

După recuperarea aleasă, verificați dacă montarea are opțiunile dorite și poate efectua o scriere în siguranță:

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

Pentru o revenire la o instantanee root, reporniți mai întâi și confirmați că sistemul implicit pornește normal. Apoi, verificați noul jurnal al kernelului pentru erori recurente Btrfs sau de dispozitiv. Un semnalizator de citire-scriere în sine nu este un certificat de stare bună: dacă apar erori repetate, opriți scrierile și reveniți la diagnosticarea stocării.