Remediați o eroare de sistem de fișiere Btrfs Read-Only pe SUSE Linux Enterprise

Încercați să salvați un fișier sau să actualizați un serviciu pe SUSE Linux Enterprise Server (SLES), iar Linux răspunde cu mesajul „Sistem de fișiere doar pentru citire”. Acest mesaj poate însemna că montarea a fost setată în mod deliberat ca fiind doar pentru citire, că ați pornit dintr-un snapshot Snapper doar pentru citire sau că Btrfs a detectat o problemă și a încetat să mai accepte scrieri pentru a proteja volumul. Aceste cauze necesită răspunsuri diferite. Începeți prin a identifica sistemul de fișiere și montarea implicate; nu forțați o remontare și nu executați o comandă de reparare înainte de a verifica jurnalele kernelului și de a proteja datele importante.

Ce înseamnă eroarea

Btrfs este un sistem de fișiere Linux de tip copiere la scriere utilizat în mod implicit pentru sistemul de fișiere rădăcină SLES în multe instalări standard. Un subvolum Btrfs este o parte montabilă independentă a unui sistem de fișiere; un snapshot este o copie la un moment dat a unui subvolum care partajează blocuri de date nemodificate. Snapper și meniul de boot SLES pot utiliza snapshot-uri pentru a recupera după modificările sistemului. Bootarea unui snapshot montează intenționat părțile incluse în modul doar pentru citire. Separat, Btrfs poate comuta în modul doar pentru citire după detectarea anumitor erori structurale pentru a evita scrieri ulterioare. SUSE documentează comportamentul snapshot-urilor în ghidul său SLES 15 SP7 Snapper ; proiectul Btrfs explică faptul că verificările structurale ale sistemului de fișiere pot comuta un volum în modul doar pentru citire pentru a preveni daune suplimentare în documentația sa de verificare a arborelui . Etichetele exacte ale meniurilor și opțiunile de recuperare disponibile pot varia în funcție de pachetul de service SLES și de aspectul spațiului de stocare.

O problemă cu permisiunile este diferită. „Permisiune refuzată” indică de obicei controlul proprietății sau al accesului; „Sistem de fișiere doar în citire” (adesea afișat ca EROFS) indică starea sistemului de fișiere sau a subvolumului. Modificarea permisiunilor de fișier cu chmodnu va face ca o montare doar în citire să fie scrisă.

Înainte să schimbi ceva

Dacă acesta este un server de producție, un volum de bază de date sau singura copie a datelor importante, contactați administratorul de sistem și confirmați copia de rezervă înainte de a încerca recuperarea. Când sistemul este încă lizibil, copiați cele mai importante fișiere într-un spațiu de stocare separat și sănătos, dacă puteți face acest lucru fără a solicita un dispozitiv defect. Btrfs poate avea modificări recente ale metadatelor doar în memorie după o eroare critică; o dezinstalare sau o repornire poate pierde acele modificări nevalidate. Dacă jurnalele menționează erori I/O, dispozitive care dispar sau resetări repetate, acordați prioritate stării spațiului de stocare și protecției datelor față de restaurarea scrierilor.

Nu executați comanda btrfs check --repairca prim pas de rutină. Proiectul Btrfs avertizează că modul de reparare poate cauza daune și nu poate remedia orice tip de corupție. Nu forțați în mod repetat o remontare citire-scriere: aceasta poate eșua imediat după ce kernelul a protejat sistemul de fișiere dintr-un motiv anume.

Pasul 1: Identificați montarea afectată

Folosește calea unde scrierea a eșuat. De exemplu, dacă un serviciu nu poate scrie în /srv/app, inspectează acea cale în loc să presupui că problema este sistemul de fișiere rădăcină:

findmnt -T /srv/app -o TARGET,SOURCE,FSTYPE,OPTIONS

Înlocuiți /srv/appcu fișierul sau directorul afectat. Verificați ieșirea pentru sursa Btrfs, ținta de montare și o opțiune rosau rw. Ținta poate fi /, o montare separată a datelor sau un subvolum. Înregistrați sursa și ținta înainte de a continua. Dacă comanda raportează un alt tip de sistem de fișiere, pașii specifici Btrfs nu se aplică acelei căi.

Verificați mesajele kernelului de la bootarea curentă pentru a afla motivul pentru care sistemul de fișiere a devenit doar pentru citire:

sudo journalctl -k -b --no-pager | grep -iE 'btrfs|I/O error|read-only|readonly'

Căutați mesaje de eroare Btrfs sau „forțat readonly”, erori de control sau de arbore, erori I/O ale dispozitivelor și deconectări ale dispozitivelor. O linie de jurnal este un indiciu, nu un diagnostic complet. Salvați mesajele și marcajele temporale relevante înainte de a reporni, deoarece jurnalele pot fi utile echipei de asistență pentru stocare sau hardware.

Pasul 2: Verificați dacă există o instantanee intenționată doar pentru citire

Dacă serverul a fost pornit dintr-un snapshot bootabil în GRUB, fișierele incluse în acel snapshot sunt concepute doar pentru citire. Acesta este un mediu de recuperare pentru verificarea stării anterioare a sistemului; nu este automat sistemul restaurat permanent. Confirmați intrarea de boot cu administratorul, apoi reporniți și selectați intrarea SLES implicită normală dacă bootarea snapshot-ului a fost accidentală. SUSE documentează faptul că bootarea unui snapshot montează părțile sistemului de fișiere incluse în modul doar pentru citire și descrie procedura separată de rollback în ghidul său de recuperare SLES 15 SP7 Snapper .

O anumită instantanee poate fi, de asemenea, doar pentru citire, chiar dacă sistemul de fișiere părinte este montat în citire-scriere. Dacă lucrați intenționat cu o instantanee, inspectați-o fără a o modifica:

sudo btrfs property get -t subvol /path/to/subvolume ro

Înlocuiți calea cu calea de montare a subvolumului. Un rezultat al [setării] ro=trueconfirmă că proprietatea subvolumului este doar pentru citire; referința proprietății Btrfs documentează acest semnalizator. Nu schimbați pur și simplu o instantanee de backup gestionată de Snapper sau primită la citire-scriere: starea doar pentru citire poate face parte din presupunerile de rollback sau backup incremental. Utilizați un flux de lucru Snapper acceptat sau creați un subvolum separat, care poate fi scris, atunci când aceasta este sarcina intenționată.

Pasul 3: Verificați configurația montării și starea spațiului de stocare

Dacă findmntrapoartele roși jurnalele nu arată nicio eroare Btrfs sau I/O, verificați intrarea de montare corespunzătoare din /etc/fstab. Este posibil ca o montare să fi fost configurată în mod deliberat doar în citire pentru recuperare, o imagine a dispozitivului sau o politică de protecție a datelor. Modificați configurația numai după confirmarea stării dorite cu proprietarul serviciului. De asemenea, verificați dacă sistemul utilizează o implementare tranzacțională sau doar în citire-root: SLES documentează astfel de configurații și fluxul de lucru al acestora pentru întreținere în ghidul său de actualizări tranzacționale . Dacă intrarea este menită în mod explicit să fie inscriptibilă, dispozitivul este sănătos și calea nu este o instantanee doar în citire, un administrator poate încerca o remontare temporară:

sudo mount -o remount,rw /mountpoint

Înlocuiți /mountpointcu ținta exactă afișată de findmnt. Aceasta nu diagnostichează și nu repară coruperea. Dacă eșuează, returnează o eroare sau jurnalele kernelului arată probleme de stocare, opriți și treceți la planificarea recuperării în loc să reîncercați cu mai multe opțiuni.

Pentru o posibilă problemă de capacitate, verificați alocarea Btrfs și starea dispozitivului:

sudo btrfs filesystem usage /mountpoint
sudo btrfs filesystem show /mountpoint

SUSE notează că rezumatele obișnuite fără disc pot fi înșelătoare în cazul Btrfs, deoarece datele și metadatele sunt alocate separat. De asemenea, instantaneele Snapper pot reține un spațiu substanțial. Cu toate acestea, „No space left on device” (Nu există spațiu rămas pe dispozitiv) nu este identic cu o eroare Btrfs read-only; identificați mesajul pe care aplicația l-a primit de fapt. Nu ștergeți instantaneele doar pentru a testa o teorie. Confirmați ce conțin și urmați mai întâi politica de păstrare aplicabilă. Consultați ghidul de depanare a sistemului de fișiere SLES 15 SP7 .

Pasul 4: Decideți dacă sistemul de fișiere necesită recuperare

Dacă în jurnalul kernelului apar erori Btrfs, dispozitivul lipsește sau o remontare este refuzată, păstrați jurnalele și aranjați o copie de rezervă verificată sau o instantanee la nivel de stocare înainte de lucrările de reparare. Pentru un volum de date non-root, planificați o fereastră de întreținere și dezmontați-l înainte de verificările offline. Pentru sistemul de fișiere root, utilizați mediul de instalare sau de salvare SUSE și urmați procedura pentru versiunea exactă SLES și semnătura de eroare. Nu ghiciți numele unui dispozitiv: un sistem de fișiere Btrfs poate acoperi mai multe dispozitive, așa că stabiliți mai întâi toți membrii și identificatorii corecți de montare sau dispozitiv.

Ghidul de administrare SLES 15 SP7 de la SUSE are o secțiune specifică pentru o partiție root Btrfs care nu poate fi montată. Acesta discută opțiunile de recuperare pentru acea eroare de pornire. Aceste instrucțiuni nu înseamnă că jurnalul fiecărui sistem de fișiere read-only montat ar trebui șters. Manualul btrfs-rescue din amonte explică faptul că btrfs rescue zero-logeste valabil pentru anumite erori de redare a jurnalelor în timpul montării și poate elimina modificările de la ultima tranzacție validată. Folosiți-l numai atunci când eroarea înregistrată se potrivește cu cazul documentat și planul de recuperare ia în considerare posibilele pierderi de date.

btrfs checkRulează implicit în modul „doar citire” pe un sistem de fișiere nemontat. Păstrați-l așa pentru evaluarea inițială și partajați rezultatul cu asistența SUSE sau cu un specialist Btrfs. Manualul btrfs-check din amonte avertizează în mod explicit împotriva utilizării --repairfără sfatul unui utilizator experimentat sau al unui dezvoltator. Nu rulați niciodată un verificator offline pe un sistem de fișiere montat, în schimbare.

Pasul 5: Verificați recuperarea

După ce cauza a fost corectată, reporniți sistemul doar atunci când planul de recuperare o solicită. Apoi, utilizați findmnt -T /path -o TARGET,SOURCE,FSTYPE,OPTIONSdin nou sistemul și confirmați că montarea dorită este de tip citire-scriere. Verificați jurnalul kernelului pentru erori Btrfs sau I/O proaspete. În cele din urmă, verificați dacă serviciul sau aplicația afectată își poate desfășura funcționarea normală și confirmați că copia de rezervă rămâne disponibilă. O remontare reușită nu dovedește că spațiul de stocare este sănătos.

Dacă sistemul de fișiere revine la modul doar pentru citire, dispozitivul se întrerupe sau erorile continuă, scrierile se opresc și se escaladează odată cu jurnalele salvate, findmntieșirea, lista de dispozitive Btrfs, nivelul pachetului service pack SLES și detaliile controlerului de stocare. Aceste dovezi ajută la distingerea unei opțiuni de instantaneu sau montare intenționate de deteriorarea suportului media, a conexiunii, a driverului sau a sistemului de fișiere și evită transformarea unei stări de protecție doar pentru citire într-o problemă de recuperare mai mare.