BTRFS(5)

BTRFS

BTRFS(5)

NUME¶

btrfs - subiecte despre sistemul de fișiere BTRFS (opțiuni de montare, atribute de fișiere acceptate și altele)

DESCRIERE¶

Acest document descrie subiecte legate de BTRFS care nu sunt specifice instrumentelor. În prezent acoperă:

1.: opțiuni de montare
2.: caracteristici ale sistemului de fișiere
3.: suport pentru fișierul de interschimb (swap)
4.: algoritmi de sumă de control
5.: comprimare
6.: interfața sysfs
7.: foperații exclusive ale sistemului de fișiere
8.: limite ale sistemului de fișiere
9.: suport pentru încărcătorul de pornire
10.: atribute de fișier
11.: modul de împărțire în zone
12.: dispozitiv de control
13.: sisteme de fișiere cu mai multe profiluri de grupuri de blocuri
14.: dispozitiv de însămânțare
15.: starea RAID56 și practici recomandate
16.: glosar
17.: model de stocare, considerente hardware

OPȚIUNI DE MONTARE¶

OPȚIUNI DE MONTARE SPECIFICE PENTRU BTRFS¶

Această secțiune descrie opțiunile de montare specifice sistemului de fișiere BTRFS. Pentru opțiunile generice de montare, consultați pagina de manual mount(8) și consultați, de asemenea, secțiunea cu detalii specifice BTRFS de mai jos. Opțiunile sunt ordonate alfabetic

NOTĂ:

Majoritatea opțiunilor de montare se aplică întregului sistem de fișiere, iar numai opțiunile din primul subvolum montat vor produce efect. Acest lucru se datorează lipsei unei implementări adecvate și se poate schimba în viitor. Aceasta înseamnă că (de exemplu) nu puteți defini opțiunile nodatacow, nodatasum sau compress pentru fiecare subvolum în parte folosind opțiunile de montare. Această problemă ar trebui rezolvată în cele din urmă, dar s-a dovedit a fi dificil de implementat corect în cadrul sistemului VFS din Linux.

Opțiunile de montare sunt procesate în ordine; doar ultima apariție a unei opțiuni produce efect și poate dezactiva alte opțiuni din cauza unor restricții (a se vedea, de exemplu, nodatacow și compress). Ieșirea comenzii mount arată ce opțiuni au fost aplicate.

acl, noacl

(implicit: activată)

Activează/dezactivează suportul pentru listele de control al accesului POSIX (ACL). Consultați pagina de manual acl(5) pentru mai multe informații despre ACL.

Suportul pentru ACL este configurabil în timpul compilării (BTRFS_FS_POSIX_ACL) și montarea eșuează dacă se solicită acl, dar funcția nu este compilată.

autodefrag, noautodefrag

(începând cu: 3.0, implicit: dezactivată)

Activează defragmentarea automată a fișierelor. Când această opțiune este activată, operațiile mici de scriere aleatorie în fișiere (cu o dimensiune de câteva zeci de kiloocteți, în prezent aproximativ 64 Kio) sunt detectate și puse în coadă pentru procesul de defragmentare. Este posibil ca această opțiune să nu fie potrivită pentru sarcini de lucru cu baze de date de mari dimensiuni.

Latența de citire poate crește din cauza citirii blocurilor adiacente care alcătuiesc intervalul pentru defragmentare, iar scrierea succesivă va fuziona blocurile în noua locație.

AVERTISMENT:

Defragmentarea cu versiuni ale nucleului Linux mai mici de 3.9 sau mai mari sau egale cu 3.14-rc2, precum și cu versiuni stabile ale nucleului Linux mai mari sau egale cu 3.10.31, 3.12.12 sau 3.13.4 va rupe legăturile de referință ale datelor COW (de exemplu, fișiere copiate cu «cp --reflink», instantanee sau date deduplicate). Acest lucru poate duce la o creștere considerabilă a spațiului utilizat, în funcție de legăturile de referință rupte.

barrier, nobarrier

(implicit: activată)

Se asigură că toate operațiile de scriere de In/Ieș trec prin memoria cache a dispozitivului și sunt stocate definitiv atunci când sistemul de fișiere se află la punctul de verificare a consistenței. De obicei, aceasta înseamnă că se trimite o comandă de golire către dispozitiv, care va sincroniza toate datele în așteptare și blocurile de metadate obișnuite, apoi va scrie super-blocul și va emite o altă comandă de golire.

Operațiile de scriere cu validare (write-flush) generează o ușoară penalizare și împiedică, de asemenea, programatorul de blocuri de In/Ieș să reordoneze cererile într-un mod mai eficient. Dezactivarea barierelor elimină această penalizare, dar va duce cu siguranță la coruperea sistemului de fișiere în cazul unei blocări sau al unei întreruperi de curent. Blocurile obișnuite de metadate ar putea să nu fie încă scrise în momentul în care noul super-bloc este stocat definitiv, presupunând că indicatorii de bloc către metadate au fost stocați permanent înainte.

Pe un dispozitiv cu o memorie cache volatilă, alimentat de la baterie, opțiunea nobarrier nu va duce la coruperea sistemului de fișiere, deoarece blocurile în așteptare ar trebui să ajungă în memoria permanentă.

clear_cache

Forțează ștergerea și reconstruirea cache-ului spațiului liber dacă ceva nu a funcționat corect.

În cazul cache-ului de spațiu liber v1, această opțiune doar șterge (și, dacă nu se utilizează nospace_cache, reconstruiește) cache-ul de spațiu liber pentru grupurile de blocuri modificate în timp ce sistemul de fișiere este montat cu această opțiune. Pentru a șterge efectiv întregul cache de spațiu liber v1, consultați btrfs check --clear-space-cache v1.

Pentru cache-ul spațiului liber v2, aceasta șterge întregul cache al spațiului liber. Pentru a face acest lucru fără a fi necesară montarea sistemului de fișiere, consultați btrfs check --clear-space-cache v2.

A se vedea, de asemenea: space_cache.

commit=<secunde>

(începând cu: 3.12, implicit: 30)

Stabilește intervalul de efectuare periodică a tranzacțiilor atunci când datele sunt sincronizate cu spațiul de stocare permanent. Valorile mai mari ale intervalului duc la acumularea în memorie a unei cantități mai mari de date nescrise, ceea ce are consecințe evidente în cazul unei blocări a sistemului. Limita superioară nu este impusă, dar se afișează un avertisment dacă aceasta depășește 300 de secunde (5 minute). A se utiliza cu precauție.

Efectuarea periodică nu este singurul mecanism de efectuare a tranzacției; aceasta poate avea loc și prin comanda explicită sync sau indirect, prin alte comenzi care afectează starea globală a sistemului de fișiere sau prin mecanisme interne ale nucleului care efectuează golirea memoriei în funcție de diverse praguri sau politici (de exemplu, cgroups).

compress, compress=<tip[:nivel]>, compress-force, compress-force=<tip[:nivel]>

(implicit: dezactivată, suport pentru niveluri începând cu: 5.1)

Controlează comprimarea datelor din fișierele BTRFS. Tipul poate fi specificat ca zlib, lzo, zstd sau no (pentru fără comprimare, utilizat la remontare). Dacă nu se specifică niciun tip, se utilizează zlib. Dacă se specifică compress-force, se va încerca întotdeauna comprimarea, dar datele pot rămâne necomprimate dacă comprimarea ar mări dimensiunea lor.

Atât zlib, cât și zstd (începând cu versiunea 5.1) permit reglarea nivelului de comprimare, nivelurile mai ridicate sacrificând viteza și memoria (zstd) în favoarea unor rapoarte de comprimare mai mari. Aceasta se poate regla prin adăugarea a două puncte (:) urmate de nivelul dorit. ZLIB acceptă intervalul [1, 9], iar ZSTD acceptă [1, 15]. Dacă nu este definit niciun nivel, ambele utilizează în prezent un nivel implicit de 3. Valoarea 0 este un alias pentru nivelul implicit.

În caz contrar, se aplică câteva metode euristice simple pentru a detecta un fișier necomprimabil. Dacă primele blocuri scrise într-un fișier nu sunt comprimabile, întregul fișier este marcat definitiv pentru a fi omis din procesul de comprimare. Deoarece această abordare este prea simplistă, opțiunea compress-force reprezintă o soluție de compromis care va comprima majoritatea fișierelor, cu prețul unor cicluri de procesor irosite în încercările eșuate. Începând cu versiunea 4.15 a nucleului, un set de algoritmi euristici a fost îmbunătățit prin utilizarea eșantionării de frecvență, a detectării modelelor repetate și a calculului entropiei Shannon pentru a evita acest lucru.

NOTĂ:

Dacă comprimarea este activată, nodatacow și nodatasum sunt dezactivate.

datacow, nodatacow

(implicit: activată)

Activează copierea datelor la scriere pentru fișierele nou create. Nodatacow implică nodatasum și dezactivează compression. Toate fișierele create sub nodatacow sunt, de asemenea, definite cu atributul de fișier NOCOW (a se vedea chattr(1)).

NOTĂ:

Dacă nodatacow sau nodatasum sunt activate, comprimarea este dezactivată.

Actualizările efectuate pe loc „direct” (fără utilizarea de tampoane, fișiere temporale pentru stocarea datelor) îmbunătățesc performanța pentru volumele de lucru care efectuează suprascrieri frecvente, cu prețul unor potențiale scrieri parțiale, în cazul în care scrierea este întreruptă (blocarea sistemului, defectarea dispozitivului).

datasum, nodatasum

(implicit: activată)

Activează calcularea sumelor de control pentru fișierele nou create. datasum implică datacow, adică modul normal de funcționare. Toate fișierele create sub nodatasum moștenesc proprietatea „fără sume de control”, însă nu există un atribut de fișier corespunzător (vezi chattr(1)).

NOTĂ:

Dacă nodatacow sau nodatasum sunt activate, comprimarea este dezactivată.

Se observă o ușoară îmbunătățire a performanței atunci când sumele de control sunt dezactivate, deoarece blocurile de metadate corespunzătoare care conțin sumele de control nu mai trebuie actualizate. Costul calculării sumelor de control pentru blocurile din memorie este mult mai redus decât cel al operațiilor de In/Ieș, iar procesoarele moderne dispun de suport hardware pentru algoritmul de calcul al sumelor de control.

degraded

(implicit: dezactivată)

Permite montări cu un număr de dispozitive mai mic decât cel impus de restricțiile profilului RAID. O montare (sau remontare) în mod citire-scriere poate eșua atunci când lipsesc prea multe dispozitive, de exemplu dacă un membru al benzii lipsește complet din RAID0.

Începând cu versiunea 4.14, verificările de constrângeri au fost îmbunătățite și se efectuează la nivel de fragment, nu la nivel de dispozitiv. Acest lucru permite montarea în regim degradat a sistemelor de fișiere cu profiluri RAID mixte pentru date și metadate, chiar dacă constrângerile privind numerele de dispozitive nu ar fi îndeplinite pentru unele dintre profiluri.

Exemplu: metadata -- raid1, data -- single, devices -- /dev/sda, /dev/sdb

Să presupunem că datele sunt stocate în întregime pe sda; în acest caz, lipsa lui sdb nu va împiedica montarea, chiar dacă, în mod normal, lipsa unui singur dispozitiv ar împiedica montarea oricărui profil single. În cazul în care unele blocuri de date sunt stocate pe sdb, atunci constrângerea single/data nu este îndeplinită și sistemul de fișiere nu poate fi montat.

device=<rută-dispozitiv>: Specifică o rută către un dispozitiv care va fi scanat în căutarea sistemului de fișiere BTRFS în timpul montării. De obicei, acest lucru se realizează automat de către un administrator de dispozitive (cum ar fi udev) sau folosind comanda btrfs device scan (de exemplu, executată din ramdisk-ul inițial). În cazurile în care acest lucru nu este posibil, opțiunea de montare dispozitiv poate fi de ajutor.
NOTĂ:

Pornirea unui sistem RAID1, de exemplu, poate eșua chiar dacă toate rutele de dispozitiv ale sistemului de fișiere sunt furnizate, deoarece nodurile dispozitivului actuale pot să nu fie descoperite de sistem în acel moment.

discard, discard=sync, discard=async, nodiscard

(implicit: asincron când dispozitivele acceptă această funcție începând cu versiunea 6.2, suport asincron începând cu versiunea: 5.6)

Activează eliminarea blocurilor de fișiere eliberate. Această opțiune este utilă pentru dispozitivele SSD/NVMe, LUN-urile cu alocare redusă sau imaginile mașinilor virtuale; totuși, pentru ca aceasta să funcționeze, fiecare strat de stocare trebuie să permită eliminarea.

În modul sincron (sync sau fără valoare specificată), lipsa funcției TRIM asincronă în coadă pe dispozitivul de stocare poate afecta grav performanța, deoarece se va încerca în schimb o operație TRIM sincronă. Funcția TRIM în coadă necesită dispozitive SATA cu cipuri mai noi decât versiunea 3.1.

Modul asincron (async) grupează extinderile (extents) în bucăți mai mari înainte de a le trimite către dispozitive pentru operațiunea TRIM. Supraîncărcarea și impactul asupra performanței ar trebui să fie neglijabile în comparație cu modul anterior, iar acesta ar trebui să fie modul preferat, dacă este necesar.

Dacă nu este necesară eliminarea imediată a blocurilor eliberate, se poate folosi instrumentul fstrim pentru a elimina toate blocurile libere într-un singur lot. Programarea unei operați TRIM într-o perioadă de activitate redusă a sistemului va preveni interferențele potențiale cu performanța altor operații. De asemenea, un dispozitiv poate ignora comanda TRIM dacă intervalul este prea mic, astfel încât executarea unei operații de eliminare în lot oferă o probabilitate mai mare de a elimina efectiv blocurile respective.

enospc_debug, noenospc_debug

(implicit: dezactivată)

Activează afișarea detaliată pentru anumite condiții ENOSPC. Este sigur de utilizat, dar poate fi zgomotos dacă sistemul ajunge aproape de starea de saturare.

fatal_errors=<acțiune>

(începând cu: 3.4, implicit: bug)

Acțiunea de efectuat în cazul apariției unei erori fatale.

bug: BUG() în cazul unei erori fatale, sistemul va rămâne în stare de blocare și poate fi încă parțial utilizabil, dar este necesară repornirea pentru funcționarea completă.
panic: panic() în cazul unei erori fatale, în funcție de alte configurații ale sistemului, aceasta poate fi urmată de o repornire. Consultați documentația parametrilor de pornire ai nucleului, de exemplu panic, oops sau crashkernel.

flushoncommit, noflushoncommit

(implicit: dezactivată)

Această opțiune forțează orice date modificate printr-o scriere într-o tranzacție anterioară să fie confirmate ca parte a confirmării curente, efectiv o sincronizare completă a sistemului de fișiere.

Acest lucru face ca starea confirmată „commited” să fie o vizualizare complet coerentă a sistemului de fișiere din perspectiva aplicației (adică include toate operațiile finalizate ale sistemului de fișiere). Acest lucru se întâmpla anterior numai atunci când era creată o iinstantanee.

Când este dezactivată, sistemul de fișiere este consecvent, dar scrierile în memoria tampon pot dura mai mult de o tranzacție confirmată.

fragment=<tip>

(depinde de opțiunea de compilare CONFIG_BTRFS_DEBUG, începând cu versiunea 4.4, implicit: dezactivată)

Un instrument de depanare care fragmentează în mod intenționat un grup de blocuri de tipul tip specificat. Tipul poate fi data, metadata sau all. Această opțiune de montare nu trebuie utilizată în afara mediilor de depanare și nu este recunoscută dacă opțiunea de configurare a nucleului CONFIG_BTRFS_DEBUG nu este activată.

nologreplay

(implicit: dezactivată, chiar și numai-pentru-citire)

Jurnalul arborescent conține actualizările în așteptare ale sistemului de fișiere până la confirmarea completă. Jurnalul este reluat la următoarea montare, lucru care poate fi dezactivat prin această opțiune. A se vedea și treelog. Rețineți că nologreplay este același cu norecovery.

AVERTISMENT:

În prezent, jurnalul arborescent este reluat chiar și cu o montare numai pentru citire! Pentru a dezactiva această funcție, montați de asemenea cu nologreplay.

max_inline=<octeți>

(implicit: min(2048, dimensiunea paginii) )

Specifică cantitatea maximă de spațiu care poate fi inclusă direct într-o frunză a arborelui b-tree de metadate. Valoarea se specifică în octeți, opțional cu sufixul K (nu se ține cont de majuscule/minuscule). În practică, această valoare este limitată de dimensiunea blocului sistemului de fișiere (denumită sectorsize la momentul „mkfs”, creării sistemului de fișiere) și de dimensiunea paginii de memorie a sistemului. În cazul limitei de dimensiune a sectorului, există un spațiu indisponibil din cauza anteturilor frunzelor b-tree. De exemplu, pentru o dimensiune a sectorului de 4 Kio, dimensiunea maximă a datelor încorporate este de aproximativ 3900 de octeți.

„Inlining-ul ”poate fi complet dezactivat prin specificarea valorii 0. Acest lucru va crește spațiul liber al blocului de date dacă dimensiunile fișierelor sunt mult mai mici decât dimensiunea blocului, dar va reduce în schimb consumul de metadate.

NOTĂ:

Valoarea implicită a fost modificată la 2048 în nucleul 4.6.

metadata_ratio=<valoare>

(implicit: 0, logică internă)

Specifică faptul că trebuie alocat 1 bloc de metadate după fiecare valoare blocuri de date. Comportamentul implicit depinde de logica internă; se încearcă menținerea unui anumit procent de spațiu neutilizat pentru metadate, dar acest lucru nu este întotdeauna posibil dacă nu există suficient spațiu disponibil pentru alocarea blocurilor. Opțiunea poate fi utilă pentru a suprascrie logica internă în favoarea alocării metadatelor dacă se preconizează că volumul de lucru va implica un număr mare de metadate (instantanee, legături de referință, atribute de fișiere, fișiere încorporate).

norecovery

(începând cu: 4.5, implicit: dezactivată)

Nu încearcă nicio recuperare de date în momentul montării. Aceasta va dezactiva logreplay și va evita alte operații de scriere. Rețineți că această opțiune este identică cu nologreplay.

NOTĂ:

Opțiunea opusă, recovery, avea inițial o semnificație diferită, dar a fost modificată pentru a asigura coerența cu alte sisteme de fișiere, în care norecovery este utilizată pentru a omite redarea jurnalului. BTRFS procedează la fel și, în general, va încerca să evite orice operații de scriere.

rescan_uuid_tree: (începând cu: 3.12, implicit: dezactivată)
Forțează verificarea și reconstruirea arborelui UUID. În mod normal, această operație nu ar trebui să fie necesară. Alternativ, arborele poate fi șters din spațiul utilizatorului prin comanda btrfs rescue clear-uuid-tree, urmând ca acesta să fie reconstruit automat în nucleu (în acest caz, opțiunea de montare nu este necesară).
rescue: (începând cu: 5.9)
Modurile care permit montarea cu structuri ale sistemului de fișiere deteriorate impun ca sistemul de fișiere să fie montat în mod „doar-citire” și nu permit remontarea în mod „citire-scriere”. Acest lucru are rolul de a oferi o gestionare unificată și mai detaliată a erorilor care afectează funcționarea sistemului de fișiere.

usebackuproot (începând cu: 5.9)
Încearcă să utilizeze sloturile rădăcină de copie de rezervă din blocul super. Înlocuiește opțiunea independentă usebackuproot
nologreplay (începând cu: 5.9)
Nu reia niciun jurnal murdar. Înlocuiește opțiunea independentă nologreplay.
ignorebadroots, ibadroots (începând cu: 5.11)
Ignoră rădăcinile arborescente deteriorate, îmbunătățește considerabil șansele de recuperare a datelor.
ignoredatacsums, idatacsums (începând cu: 5.11)
Ignoră verificarea sumei de control a datelor.
ignoremetacsums, imetacsums (începând cu: 6.12)
Ignoră verificarea sumelor de control ale metadatelor, utilă pentru conversia sumelor de control întreruptă.
all (începând cu: 5.9)
Activează toate opțiunile de recuperare acceptate.

skip_balance

(începând cu: 3.3, implicit: dezactivată)

Omite reluarea automată a unei operații de echilibrare întrerupte. Operația poate fi reluată ulterior cu comanda btrfs balance resume, sau starea de pauză poate fi eliminată cu comanda btrfs balance cancel. Comportamentul implicit este reluarea unei operații de echilibrare întrerupte imediat după montarea sistemului de fișiere.

space_cache, space_cache=<versiune>, nospace_cache

(nospace_cache începând cu: 3.2, space_cache=v1 și space_cache=v2 începând cu: 4.5, implicit: space_cache=v2)

Opțiuni pentru gestionarea cache-ului de spațiu liber. Cache-ul de spațiu liber îmbunătățește considerabil performanța la citirea în memorie a spațiului liber din grupurile de blocuri. Cu toate acestea, gestionarea cache-ului de spațiu consumă anumite resurse, inclusiv o cantitate redusă de spațiu pe disc.

Există două variante de implementare a cache-ului de spațiu liber. Varianta inițială, denumită v1, era considerată o opțiune implicită sigură, dar a fost înlocuită de v2. Cache-ul de spațiu v1 poate fi dezactivat la montare folosind opțiunea nospace_cache, fără a fi necesară ștergerea conținutului.

În cazul sistemelor de fișiere foarte mari (de ordinul tera-octeților) și al anumitor sarcini de lucru, performanța cache-ului de spațiu v1 se poate reduce drastic. Implementarea v2, care adaugă un nou arbore b-tree numit „arbore de spațiu liber”, rezolvă această problemă. Odată activat, cache-ul de spațiu v2 va fi utilizat întotdeauna și nu poate fi dezactivat decât dacă este golit. Utilizați clear_cache,space_cache=v1 sau clear_cache,nospace_cache pentru a face acest lucru. Dacă v2 este activată, cache-ul de spațiu v1 va fi șters (la prima montare), iar nucleele fără suport v2 vor putea monta sistemul de fișiere doar în modul numai citire. Pe un sistem de fișiere nemontat, cache-urile (ambele versiuni) pot fi șterse cu „btrfs check --clear-space-cache”.

Comenzile btrfs-check(8) și :doc:`mkfs.btrfs au suport complet pentru cache-ul spațiului liber v2 începând cu versiunea v4.19.

Dacă nu este specificată în mod explicit o versiune, va fi aleasă implementarea implicită, care este v2.

ssd, ssd_spread, nossd, nossd_spread

(implicit: SSD detectat automat)

Opțiuni pentru controlul schemelor de alocare a SSD-urilor. În mod implicit, BTRFS va activa sau dezactiva optimizările pentru SSD-uri în funcție de tipul dispozitivului (rotativ sau nerotativ). Acest lucru este determinat de conținutul fișierului /sys/block/DEV/queue/rotational. Dacă valoarea este 0, opțiunea ssd este activată. Opțiunea nossd va dezactiva detectarea automată.

Optimizările utilizează absența penalizării de căutare care este inerentă pentru dispozitivele rotative. Blocurile pot fi de obicei scrise mai rapid și nu sunt transferate către fire de execuție separate.

NOTĂ:

Începând cu versiunea 4.14, optimizările de dispunere a blocurilor au fost eliminate. Acestea erau utile pentru primele generații de dispozitive SSD. Stratul FTL (Flash Translation Layer) al acestora nu era eficient, iar optimizarea urma să îmbunătățească rezistența la uzură printr-o aliniere mai bună a blocurilor. Acest lucru nu mai este valabil în cazul dispozitivelor SSD moderne, iar optimizarea nu mai aducea niciun beneficiu real. În plus, aceasta ducea la o fragmentare crescută. Ajustarea dispunerii a fost păstrată intactă pentru opțiunea ssd_spread.

Opțiunea de montare ssd_spread încearcă să aloce spațiu neutilizat în blocuri mai mari și aliniate, putând oferi performanțe mai bune pe SSD-urile de gamă inferioară. ssd_spread include implicit ssd, activând astfel și toate celelalte algoritme pentru SSD-uri. Opțiunea nossd va dezactiva toate opțiunile pentru SSD-uri, în timp ce nossd_spread dezactivează doar ssd_spread.

subvol=<ruta>: Montează sub-volumul din ruta în loc de subvolumul de nivel superior. ruta este întotdeauna tratată ca fiind relativă la subvolumul de nivel superior. Această opțiune de montare prevalează asupra setului implicit de subvolum pentru sistemul de fișiere dat.
subvolid=<id-_sub-vol>: Montează subvolumul specificat printr-un număr id-_sub-vol, în loc de subvolumul de nivel superior. Puteți utiliza comanda btrfs subvolume list sau btrfs subvolume show pentru a vizualiza numerele de identificare ale sub-volumelor. Această opțiune de montare înlocuiește setul de sub-volume implicit pentru sistemul de fișiere respectiv.
NOTĂ:

Dacă sunt specificate atât subvolid cât și subvol, acestea trebuie să indice același subvolum, altfel montarea va eșua.

thread_pool=<număr>

(implicit: min(NR.CPU-uri + 2, 8) )

Numărul de fire de execuție care trebuie pornite. NRCPUS reprezintă numărul de procesoare active detectate în momentul montării. Un număr mic duce la un paralelism redus în procesarea datelor și a metadatelor, iar un număr mare ar putea duce la o scădere a performanței din cauza intensificării conflictelor de blocare, a planificării proceselor, a „bouncing-ului (respingerii)” liniilor de cache sau a transferurilor costisitoare de date între memoriile locale ale procesoarelor.

treelog, notreelog

(implicit: activată)

Activează jurnalul arborescent utilizat pentru operațiile de scriere fsync și O_SYNC. Jurnalul arborescent stochează modificările fără a fi necesară o sincronizare completă a sistemului de fișiere. Operațiile din jurnal sunt salvate la sincronizare și la confirmarea tranzacției. Dacă sistemul se blochează între două astfel de sincronizări, operațiile din jurnalul arborescent aflate în așteptare sunt reluate în timpul montării.

AVERTISMENT:

În prezent, jurnalul arborescent este redat chiar și cu o montare numai pentru citire! Pentru a dezactiva această funcție, montați de asemenea cu nologreplay.

Jurnalul ar putea conține fișiere/directoare noi, care nu ar exista pe un sistem de fișiere montat dacă jurnalul nu este reluat.

usebackuproot

(începând cu: 4.6, implicit: dezactivată)

Activează încercările de autorecuperare în cazul în care se găsește o rădăcină greșită a arborelui în momentul montării. În prezent, aceasta scanează o listă de rezervă a mai multor rădăcini anterioare ale arborelui și încearcă să utilizeze prima care poate fi citită. Acest lucru poate fi utilizat și în cazul montărilor numai-pentru-citire.

NOTĂ:

Această opțiune a înlocuit recovery, care a fost depreciată.

user_subvol_rm_allowed

(implicit: dezactivată)

Permite ca subvolumele să fie șterse de către proprietarul lor. În caz contrar, numai utilizatorul root poate face acest lucru.

NOTĂ:

În trecut, orice utilizator putea crea o instantanee chiar dacă nu era proprietarul sub-volumului sursă; din acest motiv, ștergerea subv-olumului a fost restricționată. Crearea subvolumului a fost restricționată, dar această opțiune de montare este încă necesară. Aceasta este o problemă de utilizare. Începând cu versiunea 4.18, apelul de sistem rmdir(2) poate șterge un sub-volum gol la fel ca un director obișnuit. Dacă acest lucru este posibil poate fi detectat în timpul rulării, consultați caracteristica rmdir_subvol în secțiunea CARACTERISTICI ALE SISTEMULUI DE FIȘIERE.

OPȚIUNI DE MONTARE DEPRECIATE¶

Listează opțiunile de montare care au fost eliminate, păstrate pentru compatibilitate cu versiunile anterioare.

recovery: (începând cu: 3.2, implicit: dezactivată, depreciată începând cu: 4.5)
NOTĂ:

Această opțiune a fost înlocuită de usebackuproot și nu trebuie utilizată, dar va funcționa pe nucleele 4.5+.

inode_cache, noinode_cache: (eliminată în: 5.11, începând cu: 3.0, implicit: dezactivată)
NOTĂ:

Funcționalitatea a fost eliminată în versiunea 5.11, iar orice date vechi create prin utilizarea anterioară a opțiunii inode_cache pot fi eliminate prin btrfs rescue clear-ino-cache.

check_int, check_int_data, check_int_print_mask=<valoare>

(eliminată în: 6.7, începând cu: 3.0, implicit: dezactivată)

Aceste opțiuni de depanare controlează comportamentul modulului de verificare a integrității (este necesară opțiunea de configurare BTRFS_FS_CHECK_INTEGRITY). Scopul principal este de a verifica dacă toate blocurile dintr-o anumită perioadă de tranzacționare sunt legate în mod corespunzător.

check_int activează modulul de verificare a integrității, care examinează toate cererile de scriere în bloc pentru a asigura coerența pe disc, cu un cost mare de memorie și CPU.

check_int_data include date de extindere (extent) în verificările de integritate și implică opțiunea check_int.

check_int_print_mask acceptă o mască de biți cu valori BTRFSIC_PRINT_MASK_*, așa cum sunt definite în fs/btrfs/check-integrity.c, pentru a controla comportamentul modulului de verificare a integrității.

Pentru mai multe informații, consultați comentariile din partea de sus a fișierului fs/btrfs/check-integrity.c.

NOTE PRIVIND OPȚIUNILE DE MONTARE GENERICE¶

Unele dintre opțiunile generale de montare din mount(8) care afectează BTRFS și merită menționate.

context: Contextul se referă la contextele SELinux și la definițiile politicilor transmise ca opțiuni de montare. Acest lucru funcționează corect începând cu versiunea v6.8 (deoarece analizatorul opțiunilor de montare din BTRFS a fost adaptat la noul API care înțelege și opțiunile).
noatime: În cazul sarcinilor de lucru cu acces intens la citire, specificarea opțiunii noatime îmbunătățește semnificativ performanța, deoarece nu este necesară scrierea de informații noi privind timpul de acces. Fără această opțiune, valoarea implicită este relatime, care reduce doar numărul de actualizări atime ale nodurilor-i în comparație cu tradiționalul strictatime. Cel mai rău caz pentru actualizările atime sub relatime apare atunci când sunt citite multe fișiere al căror atime este mai vechi de 24 de ore și care au fost recent salvate în instantanee. În acest caz, atime este actualizat și COW are loc — pentru fiecare fișier — în bloc. Vezi și
Rețineți că noatime poate afecta aplicațiile care se bazează pe timpul de funcționare atime, cum ar fi venerabilul Mutt (cu excepția cazului în care utilizați căsuțele poștale maildir).

CARACTERISTICI ALE SISTEMULUI DE FIȘIERE¶

Setul de bază de caracteristici ale sistemului de fișiere se extinde în timp. Compatibilitatea cu versiunile anterioare este menținută, iar caracteristicile sunt opționale și trebuie solicitate explicit, astfel încât utilizarea accidentală să nu creeze incompatibilități.

Există mai multe clase și instrumentele corespunzătoare pentru gestionarea funcțiilor:

at mkfs time only: Acest lucru este valabil în special pentru structurile de bază, cum ar fi dimensiunea nodului b-tree sau algoritmul de sumă de control. Pentru mai multe detalii, consultați mkfs.btrfs(8).
după mkfs, pe un sistem de fișiere nemontat: Funcționalități care pot optimiza structurile interne sau adăuga structuri noi pentru a susține funcționalități noi; consultați btrfstune(8). Comanda btrfs inspect-internal dump-super /dev/sdx va genera un „dump” al supeblocului; puteți corela valoarea lui incompat_flags cu caracteristicile enumerate mai jos
după mkfs, pe un sistem de fișiere montat: Caracteristicile unui sistem de fișiere (cu un anumit UUID) sunt enumerate în /sys/fs/btrfs/UUID/features/, câte un fișier pentru fiecare caracteristică. Starea este stocată în interiorul fișierului. Valoarea 1 indică faptul că caracteristica este activată și funcțională, în timp ce 0 înseamnă că caracteristica a fost activată la montare, dar a fost dezactivată ulterior.
În directorul /sys/fs/btrfs/features/ se poate afla dacă o anumită caracteristică poate fi activată pe un sistem de fișiere montat, un fișier pentru fiecare caracteristică. Valoarea 1 înseamnă că funcția poate fi activată.

Lista caracteristicilor (vedeți și secțiunea mkfs.btrfs(8) CARACTERISTICI ALE SISTEMULUI DE FIȘIERE):

big_metadata

(începând cu: 3.4)

sistemul de fișiere utilizează nodesize pentru blocurile de metadate, care pot fi mai mari decât dimensiunea paginii

block_group_tree

(începând cu: 6.1)

reprezentarea elementelor grupului de blocuri folosind un arbore b-tree dedicat, ceea ce poate reduce considerabil timpul de montare pentru sistemele de fișiere mari

compress_lzo

(începând cu: 2.6.38)

comprimarea lzo a fost utilizată pe sistemul de fișiere, fie ca opțiune de montare, fie prin btrfs filesystem defrag.

compress_zstd

(începând cu: 4.14)

comprimarea zstd a fost utilizată pe sistemul de fișiere, fie ca opțiune de montare, fie prin btrfs filesystem defrag.

default_subvol

(începând cu: 2.6.34)

subvolumul implicit a fost definit pe sistemul de fișiere

extended_iref

(începând cu: 3.7)

a fost mărită limita legăturilor dure pe fișier într-un director la 65536, nucleele mai vechi acceptau un număr variabil de legături dure în funcție de suma tuturor dimensiunilor numelor de fișiere care pot fi stocate într-un bloc de metadate

free_space_tree

(începând cu: 4.5)

reprezentarea spațiului liber folosind un arbore b-tree dedicat, succesor al cache-ului de spațiu v1

metadata_uuid

(începând cu: 5.0)

UUID-ul principal al sistemului de fișiere este metadata_uuid, care stochează noul UUID numai în super-bloc, în timp ce toate blocurile de metadate au încă UUID-ul definit la momentul mkfs, a se vedea btrfstune(8) pentru mai multe detalii

mixed_backref

(începând cu: 2.6.31)

ultima modificare majoră a formatului discului, referințe inversate îmbunătățite, acum implicite

mixed_groups

(începând cu: 2.6.37)

grupuri de blocuri mixte de date și metadate, adică datele și metadatele nu sunt separate și ocupă aceleași grupuri de blocuri; acest mod este potrivit pentru volume mici, deoarece nu există restricții privind modul în care trebuie utilizat spațiul rămas (spre deosebire de modul „split”, în care spațiul gol al metadatelor nu poate fi utilizat pentru date și viceversa)

pe de altă parte, aspectul final este destul de imprevizibil și posibil foarte fragmentat, ceea ce înseamnă performanțe mai slabe

no_holes

(începând cu: 3.14)

reprezentare îmbunătățită a extensiilor fișierelor în care golurile nu sunt stocate în mod explicit ca extensie, economisește câteva procente din metadate dacă se utilizează fișiere disperse

raid1c34

(începând cu: 5.5)

mod RAID1 extins cu copii pe 3 sau, respectiv, pe 4 dispozitive

raid_stripe_tree

(începând cu: 6.7)

un arbore separat pentru urmărirea extensiilor fișierelor pe profilurile RAID

RAID56

(începând cu: 3.9)

sistemul de fișiere conține sau a conținut un profil RAID56 de grupuri de blocuri

rmdir_subvol

(începând cu: 4.18)

indică faptul că rmdir(2) syscall poate șterge un sub-volum gol la fel ca un director obișnuit. Rețineți că această caracteristică depinde doar de versiunea nucleului.

skinny_metadata

(începând cu: 3.10)

metadate de dimensiuni reduse pentru referințele de extindere(extent), economisesc câteva procente din metadate

send_stream_version

(începând cu: 5.10)

numărul celei mai recente versiuni acceptate pentru fluxul de trimitere

simple_quota

(începând cu: 6.7)

contabilizarea simplificată a cotelor

supported_checksums

(începând cu: 5.5)

lista algoritmilor de sumă de control acceptați de modulul nucleului, modulele respective sau modulele integrate care implementează algoritmii trebuie să fie prezente pentru a monta sistemul de fișiere, a se vedea secțiunea ALGORITMI DE SUMĂ DE CONTROL.

supported_sectorsizes

(începând cu: 5.13)

listează valorile acceptate ca dimensiuni ale sectoarelor (mkfs.btrfs --sectorsize) de către nucleul în execuție

supported_rescue_options

(începând cu: 5.11)

listează valorile pentru opțiunea de montare rescue care sunt acceptate de nucleul în execuție, a se vedea btrfs(5)

zoned

(începând cu Linux 5.12)

modul „zoned” este prietenos cu alocarea/scrierea pentru dispozitivele împărțite în zone, gestionate de gazdă, spațiul de alocare este împărțit în zone de dimensiuni fixe care trebuie actualizate secvențial, a se vedea secțiunea MODUL „ZONED”

SUPORT PENTRU FIȘIERUL DE INTERSCHIMB (SWAP)¶

Un fișier swap, atunci când este activ, reprezintă o zonă de swap stocată pe un fișier. Este acceptat începând cu versiunea 5.0 a nucleului. Folosiți comanda swapon(8) pentru a-l activa; până atunci (respectiv, din nou, după dezactivarea acestuia cu comanda swapoff(8)), acesta este doar un fișier normal (cu NODATACOW activat) pentru care restricțiile speciale pentru fișierele swap active nu se aplică.

Există câteva limitări ale implementării în BTRFS și subsistemul swap Linux:

filesystem - trebuie să fie un singur dispozitiv
trebuie să aibă doar un singur profil de date
subvolume - nu se poate crea o instantanee a acestuia dacă conține fișiere swap active
swapfile - trebuie să fie prealocat (adică fără goluri)
swapfile - trebuie să fie NODATACOW (adică, de asemenea, NODATASUM, fără comprimare)

Limitările decurg în special din arhitectura bazată pe COW și din stratul de cartografiere a blocurilor, care permite funcționalități avansate precum realocarea și sistemele de fișiere pe mai multe dispozitive. Cu toate acestea, subsistemul swap se bazează pe o cartografiere mai simplă și nu acceptă modificări în fundal ale locației blocurilor de fișiere odată ce acestea au fost alocate spațiului swap. Constrângerile menționate mai sus (un singur dispozitiv și un singur profil) sunt legate de fișierul swap în sine, adică de extinderi(extents) și de amplasarea acestora. Este posibil să se creeze un fișier swap pe un sistem de fișiere cu mai multe dispozitive, atâta timp cât extinderile se află pe un singur dispozitiv, dar acest lucru nu poate fi influențat de utilizator și depinde de fragmentarea spațiului liber și de spațiul neutilizat disponibil pentru noi blocuri.

Cu fișiere swap active, următoarele operațiuni asupra întregului sistem de fișiere vor omite extensiile (extents) fișierului swap sau pot eșua:

balance - grupurile de blocuri cu extinderi (extents) ale oricăror fișiere swap active sunt omise și raportate, restul vor fi procesate în mod normal
resize grow - neafectat
resize shrink - funcționează atâta timp cât extensiile (extents) oricăror fișiere swap active se află în afara intervalului redus
device add - dacă noile dispozitive nu interferează cu niciun fișier swap deja activ, această operație va funcționa, însă nu se va putea activa niciun fișier swap nou după aceea
device delete - dacă dispozitivul a fost adăugat conform instrucțiunilor de mai sus, acesta poate fi și șters
device replace - idem

Când nu există fișiere swap active și se execută o operație exclusivă asupra întregului sistem de fișiere (de exemplu, echilibrare, ștergere dispozitiv, micșorare), fișierele swap nu pot fi activate temporar. Operația trebuie să se încheie mai întâi.

Pentru a crea și activa un fișier swap, executați următoarele comenzi:

# truncate -s 0 swapfile
# chattr +C swapfile
# fallocate -l 2G swapfile
# chmod 0600 swapfile
# mkswap swapfile
# swapon swapfile

Începând cu versiunea 6.1, este posibil să creați fișierul swap cu o singură comandă (cu excepția activării):

# btrfs filesystem mkswapfile --size 2G swapfile
# swapon swapfile

Rețineți că UUID-ul returnat de instrumentul mkswap identifică „sistemul de fișiere” swap și, deoarece este stocat într-un fișier, acesta nu este, în general, vizibil și nu poate fi utilizat ca identificator, spre deosebire de cazul în care s-ar afla pe un dispozitiv de blocuri.

Odată activat, fișierul va apărea în /proc/swaps:

# cat /proc/swaps
Filename          Type          Size           Used      Priority
/ruta-la/swapfile    file          2097152        0         -2

Fișierul swap poate fi creat printr-o operație unică sau, odată creat corespunzător, poate fi activat la fiecare pornire a sistemului prin comanda «swapon -a» (de obicei lansată de gestionarul de servicii). Adăugați următoarea intrare în /etc/fstab, presupunând că sistemul de fișiere care furnizează /ruta-la a fost deja montat la acest moment. Se pot defini și opțiuni de montare suplimentare relevante pentru fișierul swap (cum ar fi prioritatea, nu opțiunile de montare BTRFS).

/ruta_la/swapfile       none        swap        defaults      0 0

De acum înainte, sub-volumul care conține fișierul swap activ nu poate fi inclus într-o instantanee până când fișierul swap nu este dezactivat din nou cu comanda swapoff. În acest moment, fișierul swap devine un fișier obișnuit, iar sub-volumul poate fi inclus din nou într-o instantanee, deși acest lucru ar împiedica o nouă activare a oricărui fișier swap care a fost inclus într-o instantanee. Se pot crea și activa fișiere swap noi (care nu au fost incluse într-o instantanee).

În caz contrar, un fișier swap inactiv nu afectează subvolumul care îl conține. Activarea creează un statut temporar în memorie și împiedică unele operații cu fișiere, dar nu este stocată permanent.

HIBERNARE¶

Un fișier de swap poate fi utilizat pentru hibernare, dar acest lucru nu este chiar atât de simplu. Înainte de hibernare, trebuie să se scrie o poziție de reluare în fișierul „/sys/power/resume_offset” sau trebuie definit parametrul de linie de comandă al nucleului resume_offset.

Valoarea este decalajul fizic pe dispozitiv. Rețineți că aceasta nu este aceeași valoare cu filefrag afișată ca decalaj fizic!

Sistemul de fișiere Btrfs utilizează o corespondență între adresele logice și cele fizice, însă, în acest caz, adresa fizică poate fi asociată în continuare cu una sau mai multe adrese de bloc fizic specifice dispozitivului. Decalajul fizic specific dispozitivului este cel care se pretează a fi utilizat ca poziția de reluare.

Începând cu versiunea 6.1, există o comandă %btrfs inspect-internal map-swapfile care afișează decalajul fizic al dispozitivului și valoarea ajustată pentru /sys/power/resume_offset. Rețineți că valoarea este împărțită la dimensiunea paginii, adică nu reprezintă decalajul în sine.

# btrfs filesystem mkswapfile swapfile
# btrfs inspect-internal map-swapfile swapfile
Physical start: 811511726080
Resume offset:     198122980

Pentru scripturi și comoditate, opțiunea -r va afișa doar decalajul:

# btrfs inspect-internal map-swapfile -r swapfile
198122980

Comanda map-swapfile verifică, de asemenea, toate cerințele, adică lipsa golurilor, dispozitiv unic etc.

SOLUȚIONAREA PROBLEMELOR¶

Dacă activarea fișierului swap eșuează, verificați dacă ați urmat toți pașii de mai sus sau verificați jurnalul de sistem (de exemplu, dmesg sau journalctl) pentru mai multe informații.

În mod special, instrumentul swapon se închide cu un mesaj care nu precizează ce anume a eșuat:

# swapon /ruta-la/swapfile
swapon: /ruta-la/swapfile: swapon a eșuat: argument nevalid

Motivul specific va fi probabil înregistrat în jurnalul de sistem de către modulul btrfs:

# journalctl -t kernel | grep swapfile
kernel: BTRFS warning (device sda): swapfile must have single data profile

ALGORITMI DE SUMĂ DE CONTROL¶

Datele și metadatele sunt verificate prin sumă de control în mod implicit. Suma de control este calculată înainte de scriere și verificată după citirea blocurilor de pe dispozitive. Întregul bloc de metadate are o sumă de control integrată, stocată în antetul nodului arborelui b-tree. Fiecare bloc de date are o sumă de control separată, stocată în arborele de sume de control.

NOTĂ:

Deoarece suma de control a datelor este calculată chiar înainte de trimiterea către dispozitivul bloc, btrfs are o cerință strictă ca blocul de date corespunzător să nu fie modificat până la finalizarea operației de scriere.

Această cerință este îndeplinită în cazul unei scrieri cu memorie tampon, deoarece Btrfs deține controlul deplin asupra cache-ului de pagini; însă o scriere directă (O_DIRECT) ocolește cache-ul de pagini, iar Btrfs nu poate controla memoria tampon de In/Ieș directă (deoarece aceasta se poate afla în memoria spațiului de utilizator) Astfel, este posibil ca un program din spațiul utilizatorului să modifice memoria tampon de scriere directă înainte ca aceasta să fie complet rescrisă, iar acest lucru poate duce la o neconcordanță a sumei de control a datelor.

Pentru a evita acest lucru, nucleul începând cu versiunea 6.14 va forța o operație de scriere directă să treacă la modul cu memorie tampon, în cazul în care nodul-i necesită o sumă de control a datelor. Acest lucru va implica o ușoară scădere a performanței. Dacă aveți nevoie de operații de scriere directă cu zero copii, activați fanionul NODATASUM pentru nodul-i și asigurați-vă că memoria tampon pentru operațiile de In/Ieș directe este aliniată complet la dimensiunea blocului.

Sunt acceptați mai mulți algoritmi de sumă de control. Algoritmul implicit și compatibil cu versiunile anterioare este crc32c. Începând cu versiunea 5.5 a nucleului, există încă trei algoritmi cu caracteristici diferite și compromisuri în ceea ce privește viteza și rezistența. Lista de mai jos vă poate ajuta să decideți pe care dintre aceștia să îl alegeți.

CRC32C (rezumat de 32 biți): Implicit, cea mai bună compatibilitate cu versiunile anterioare. Foarte rapid, procesoarele moderne au suport la nivel de instrucțiuni, nu este rezistent la coliziuni, dar are totuși capacități bune de detectare a erorilor.
XXHASH (rezumat de 64 biți): Poate fi utilizat ca succesor al CRC32C. Foarte rapid, optimizat pentru procesoarele moderne care utilizează pipeline de instrucțiuni, rezistență bună la coliziuni și detectare a erorilor.
SHA256 (rezumat de 256 biți): Algoritm de sum[ de control cu putere criptografică. Relativ lent, dar cu posibilitate de accelerare a instrucțiunilor CPU sau carduri hardware specializate. Certificat FIPS și utilizat pe scară largă.
BLAKE2b (rezumat de 256 biți): Algoritm de sumă de control cu putere criptografică. Relativ rapid, cu posibilitate de accelerare prin procesor folosind extensii SIMD. Nu este standardizat, dar se bazează pe BLAKE, care a fost finalist la SHA3 și este utilizat pe scară largă. Algoritmul folosit este BLAKE2b-256, optimizat pentru platforme pe 64 de biți.

Valoarea dimensiune rezumat influențează dimensiunea totală a sumelor de control ale blocurilor de date stocate în sistemul de fișiere. Blocurile de metadate au o dimensiune fixă de până la 256 de biți (32 de octeți), astfel încât nu se înregistrează nicio creștere. Fiecare bloc de date are o sumă de control stocată separat, cu un volum suplimentar reprezentat de frunzele arborelui b-tree.

Performanța relativă aproximativă a algoritmilor, măsurată în comparație cu CRC32C utilizând implementări pe un procesor Intel de generația a 11-a, cu frecvența de 3,6 GHz:

Rezumat	Cicluri/4Kio	Raport	Implementarea
CRC32C	470	1.00	instrucțiuni CPU, combinație PCL
XXHASH	870	1.9	referință implementare
SHA256	7600	16	libgcrypt
SHA256	8500	18	openssl
SHA256	8700	18	botan
SHA256	32000	68	încorporat, instrucțiune CPU
SHA256	37000	78	libsodium
SHA256	78000	166	încorporat, referință implementare
BLAKE2b	10000	21	încorporat/AVX2
BLAKE2b	10900	23	libgcrypt
BLAKE2b	13500	29	încorporat/SSE41
BLAKE2b	13700	29	libsodium
BLAKE2b	14100	30	openssl
BLAKE2b	14500	31	kcapi
BLAKE2b	14500	34	încorporat, referință implementare

Multe nuclee sunt configurate cu SHA256 integrat, nu sub formă de modul. Până la versiunea v6.15 a nucleului, versiunile accelerate sunt totuși furnizate de module și trebuie încărcate în mod explicit (modprobe sha256) înainte de montarea sistemului de fișiere pentru a le putea utiliza. Puteți verifica în /sys/fs/btrfs/FSID/checksum care dintre ele este utilizat. Dacă vedeți sha256-generic, atunci ar fi bine să demontați și să montați din nou sistemul de fișiere. Nu este posibilă modificarea acestui lucru pe un sistem de fișiere montat.

Începând cu nucleul v6.16, implementarea accelerată este utilizată întotdeauna, dacă este disponibilă.

Verificați fișierul /proc/crypto. Când implementarea este integrată, veți găsi:

name         : sha256
driver       : sha256-generic
module       : kernel
priority     : 100
...

În timp ce pentru implementarea accelerată este, de exemplu:

name         : sha256
driver       : sha256-avx2
module       : sha256_ssse3
priority     : 170
...

COMPRIMARE¶

Btrfs acceptă comprimarea transparentă a fișierelor. Sunt disponibili trei algoritmi: ZLIB, LZO și ZSTD (începând cu versiunea 4.14), cu diferite niveluri. Comprimarea se realizează la nivelul extinderilor fișierelor, iar algoritmul este selectat prin proprietățile fișierului, opțiunile de montare sau prin comanda de defragmentare. Puteți avea un singur punct de montare btrfs care conține unele fișiere necomprimate, altele comprimate cu LZO, altele cu ZLIB, de exemplu (deși s-ar putea să nu doriți acest lucru, este acceptat).

Odată ce comprimarea este activată, toate datele nou scrise vor fi comprimate, adică datele existente rămân neschimbate. Datele sunt împărțite în blocuri mai mici (128 Kio) înainte de comprimare, pentru a permite rescrierile aleatorii fără a afecta semnificativ performanța. Datorită numărului crescut de extinderi (extents), consumul de metadate este mai mare. Blocurile sunt comprimate în paralel.

Algoritmii pot fi caracterizați după cum urmează în ceea ce privește compromisurile dintre viteză și raport:

ZLIB

mai lent, raport de comprimare mai mare
niveluri: de la 1 la 9, atribuite direct, nivelul implicit este 3
compatibilitate bună cu versiunile anterioare

LZO

comprimare și decomprimare mai rapide decât ZLIB, raport de comprimare mai slab, conceput pentru a fi rapid
fără nivele
compatibilitate bună cu versiunile anterioare

ZSTD

comprimare comparabilă cu ZLIB, cu viteze mai mari de comprimare/decomprimare și raport diferit
niveluri: -15..15, atribuite direct, valoarea implicită este 3
suport, începând cu: 4.14
niveluri 1..15 acceptat începând cu versiunea 5.1
niveluri -15..-1 acceptat începând cu versiunea 6.15

Diferențele depind de setul de date concret și nu pot fi exprimate printr-o singură valoare numerică sau recomandare. Nivelurile mai ridicate consumă mai mult timp de procesare și s-ar putea să nu aducă o îmbunătățire semnificativă, în timp ce nivelurile mai scăzute se află aproape de timpul real.

CUM SE ACTIVEAZĂ COMPRIMAREA¶

De obicei, comprimarea poate fi activată la nivelul întregului sistem de fișiere, fiind specificată pentru punctul de montare. Rețineți că opțiunile de montare pentru comprimare sunt comune tuturor montărilor aceluiași sistem de fișiere, fie că este vorba de montări de tip „bind” sau de montări de sub-volume. Vă rugăm să consultați secțiunea OPȚIUNI DE MONTARE din btrfs(5).

$ mount -o compress=zstd /dev/sdx /mnt

Aceasta va activa algoritmul zstd la nivelul implicit (care este 3). Nivelul poate fi specificat și manual, de exemplu zstd:3. Nivelurile mai ridicate oferă o compresie mai bună, dar necesită mai mult timp. La rândul său, acest lucru poate duce la o latență de scriere mai mare; nivelurile mai scăzute sunt potrivite pentru comprimarea în timp real și, pe un procesor suficient de rapid, nu provoacă scăderi semnificative ale performanței.

$ btrfs filesystem defrag -czstd fișier

Comanda de mai sus va iniția defragmentarea întregului fișier file și va aplica compresia, indiferent de opțiunea de montare. Nivelul de compresie poate fi specificat și cu argumentul --level sau -L începând cu versiunea 6.14. Algoritmul de compresie nu este persistent și se aplică doar comenzii de defragmentare; pentru orice alte operațiuni de scriere se aplică alte opțiuni de compresie.

Configurările persistente pentru fiecare fișier în parte pot fi configurate în două moduri:

$ chattr +c fișier
$ btrfs property set fișier compression zstd

Prima comandă utilizează interfața învechită a atributelor de fișier moștenită de la sistemul de fișiere ext2 și nu este flexibilă, așa că, în mod implicit, este activată comprimarea zlib. Cealaltă comandă definește o proprietate a fișierului folosind algoritmul specificat. Notă: definirea nivelului în acest mod nu este încă implementată.

NIVELURI DE COMPRIMARE¶

Suportul pentru niveluri al ZLIB a fost adăugat în v4.14, LZO nu oferă suport pentru niveluri (implementarea nucleului oferă doar unul), suportul pentru niveluri ZSTD a fost adăugat în v5.1, iar nivelurile negative în v6.15.

Există 9 niveluri ZLIB acceptate (de la 1 la 9), care corespund unu la unu între opțiunea de montare și nivelul definit de algoritm. Valoarea implicită este nivelul 3, care oferă un raport de comprimare destul de bun și este totuși destul de rapid. Diferența în ceea ce privește gradul de comprimare între nivelurile 7, 8 și 9 este comparabilă, dar nivelurile superioare durează mai mult.

Suportul ZSTD include nivelurile -15..15, un subset al gamei complete oferite de ZSTD. Nivelurile -15..-1 sunt în timp real, cu un raport de compresie mai slab, nivelurile 1..3 sunt aproape în timp real, cu o compresie bună, 4..8 sunt mai lente, cu o compresie îmbunătățită, iar 9..15 depun eforturi și mai mari, deși dimensiunea fișierului rezultat s-ar putea să nu fie îmbunătățită semnificativ. Nivelurile mai ridicate necesită, de asemenea, mai multă memorie și, deoarece necesită mai multă putere de procesare, performanța sistemului este afectată.

Nivelul 0 corespunde întotdeauna valorii implicite. Nivelul de comprimare nu afectează compatibilitatea.

EXCEPȚIII¶

Orice fișier care a fost modificat de apelul de sistem fallocate va fi întotdeauna exclus de la comprimare, chiar dacă se utilizează opțiunea de montare force-compress.

Motivul este că o apelare reușită a funcției fallocate trebuie să garanteze că viitoarele operații de scriere în intervalul alocat nu vor eșua din cauza lipsei de spațiu. Acest lucru este dificil de garantat într-un sistem de fișiere COW. Pentru a reduce probabilitatea ca acest lucru să se întâmple, btrfs pre-alocă spațiu și dezactivează comprimarea pentru fișierul respectiv.

Ca soluție alternativă, se poate declanșa o rescriere comprimată pentru un astfel de fișier folosind comanda btrfs defrag. Rețineți că, dacă fișierul este accesat din nou prin apelul de sistem fallocate, acesta va fi din nou exclus din comprimare pentru toate datele noi scrise în el.

DATE INCOMPREHENSIBILE¶

Fișierele care conțin date deja comprimate sau date care nu se pot comprima eficient din cauza limitărilor de procesor și memorie ale implementărilor nucleului utilizează o logică de decizie simplă. Dacă prima porțiune de date care urmează să fie comprimată nu este mai mică decât originalul, comprimarea întregului fișier este dezactivată. Cu excepția cazului în care sistemul de fișiere este montat cu opțiunea compress-force, caz în care btrfs va încerca să comprime fiecare bloc, recurgând la stocarea versiunii necomprimate pentru fiecare bloc care ajunge să fie mai mare după comprimare. Aceasta nu este o soluție optimă și este supusă optimizărilor și dezvoltării ulterioare.

Dacă un fișier este identificat ca fiind incompresibil, se activează un fanion (NOCOMPRESS) și acesta devine persistent „sticky”. În cazul acelui fișier, comprimarea nu este efectuată decât dacă este forțată. Fanionul poate fi de asemenea activat prin chattr +m (începând cu e2fsprogs 1.46.2) sau prin proprietăți cu valoarea no sau none. O valoare goală îl va reinițializa la valoarea implicită care este aplicabilă în prezent pe sistemul de fișiere montat.

Există două modalități de detectare a datelor incomprehensibile:

încercarea efectivă de comprimare - datele sunt comprimate, dacă rezultatul nu este mai mic, este eliminat, deci acest lucru depinde de algoritm și de nivel
euristici de precomprimare - se efectuează o evaluare statistică rapidă a datelor și, în funcție de rezultat, se aplică sau se omite comprimarea, bitul NOCOMPRESS nu este activat doar pe baza euristicii, ci numai în cazul în care algoritmul de comprimare nu aduce o îmbunătățire

$ lsattr fișier
---------------------m fișier

Nu se recomandă utilizarea comprimării forțate, euristica ar trebui să decidă acest lucru, iar algoritmii de comprimare detectează intern de asemenea datele incomprehensibile.

EURISTICI PRE-COMPRIMARE¶

Heuristicile au ca scop efectuarea unor teste statistice rapide asupra datelor comprimate, pentru a evita o comprimare probabil costisitoare care s-ar dovedi ineficientă. Algoritmii de compresie ar putea avea și ei o funcție internă de detectare a datelor incompresibile, dar acest lucru generează un volum suplimentar de operații, deoarece compresia se efectuează într-un alt fir și datele trebuie oricum scrise. Heuristica este de tip „doar-citire” și poate utiliza memoria cache.

Testele efectuate s-au bazat pe următoarele: eșantionarea datelor, detectarea modelelor repetate pe termen lung, frecvența octeților, entropia Shannon.

COMPATIBILITATE¶

Comprimarea necesită atât sumele de control ale datelor, cât și COW, astfel încât opțiunea de montare nodatasum sau nodatasum/fanionul nodului-i nu vor avea ca rezultat comprimarea.

Citirile de In/Ieș directe ale datelor comprimate vor reveni întotdeauna la citirile stocate în memoria tampon.

Comportamentul scrierii de In/Ieș directe depinde de fanionul nodului-i. Pentru nodurile cu sumă de control a datelor, scrierile de In/Ieș directe revin întotdeauna la scrierile în tampon, putând astfel genera date comprimate dacă opțiunea de montare/fanioanele nodului-i permit acest lucru.

Pentru nodurile-i fără sume de control ale datelor, scrierile In/Ieș directe nu vor popula cache-ul paginii și, deoarece nodul-i nu are sume de control ale datelor, nu vor fi generate date comprimate.

Algoritmii de compresie au fost adăugați de-a lungul timpului, astfel încât trebuie luată în considerare și compatibilitatea versiunilor, împreună cu alte instrumente care pot accesa datele comprimate, cum ar fi încărcătoarele de pornire.

INTERFAȚA SYSFS¶

Btrfs are o interfață sysfs pentru a oferi opțiuni suplimentare.

Ruta de nivel superior este /sys/fs/btrfs/, iar structura principală a directorului este următoarea:

Ruta relativă	Descriere	Versiune
features/	Toate funcțiile acceptate	3.14
<UUID>/	UUID-ul sistemului de fișiere montat	3.14
<UUID>/allocation/	Informații privind alocarea spațiului	3.14
<UUID>/bdi/	Informații despre dispozitivul de copie de rezervă (writeback)	5.9
<UUID>/devices/<ID_DISPOZITIV>/	Legătură simbolică către fiecare dispozitiv bloc sysfs	5.6
<UUID>/devinfo/<ID_DISPOZITIV>/	Informații specifice Btrfs pentru fiecare dispozitiv	5.6
<UUID>/discard/	Renunță la statistici și parametri reglabili	6.1
<UUID>/features/	Caracteristici ale sistemului de fișiere	3.14
<UUID>/qgroups/	Informații globale despre qgroup	5.9
<UUID>/qgroups/<NIVEL>_<ID>/	Informații pentru fiecare qgroup	5.9

Pentru directorul /sys/fs/btrfs/features/, fiecare fișier reprezintă o caracteristică acceptată de nucleul actual. Majoritatea fișierelor au valoarea 0. În caz contrar, depinde de fișier, valoarea 1 înseamnă de obicei că caracteristica poate fi activată pe un sistem de fișiere montat.

Pentru directorul /sys/fs/btrfs/<UUID>/features/, fiecare fișier reprezintă o funcție activată pe sistemul de fișiere montat.

Caracteristicile au același nume în secțiunea CARACTERISTICI ALE SISTEMULUI DE FIȘIERE.

UUID¶

Fișierele din directorul /sys/fs/btrfs/<UUID>/ sunt:

bg_reclaim_threshold

(RW, începând cu: 5.19)

Procentul spațiului utilizat din spațiul total al dispozitivului pentru a începe revendicarea automată a grupului de blocuri. În principal pentru dispozitive împărțite în zone (zoned).

checksum

(RO, începând cu: 5.5)

Suma de control utilizată pentru sistemul de fișiere montat. Aceasta include atât tipul de sumă de control (consultați secțiunea ALGORITMI DE SUMĂ DE CONTROL) cât și controlorul implementat (indică în principal dacă este accelerat hardware).

clone_alignment

(RO, începând cu: 3.16)

Alinierea octeților pentru ioctl-urile clone și dedupe.

commit_stats

(RW, începând cu: 6.0)

Statisticile de performanță pentru confirmarea tranzacțiilor btrfs de la prima montare. În principal pentru scopuri de depanare.

Scrierea în acest fișier va reinițializa durata maximă de comitere (max_commit_ms) la 0. Fișierul arată astfel:

commits 70649
last_commit_ms 2
max_commit_ms 131
total_commit_ms 170840

commits - numărul de tranzacții comise de la prima montare
last_commit_ms - durata în milisecunde a ultimei comiteri
max_commit_ms - timpul maxim necesar pentru comiterea unei tranzacții de la prima montare sau ultima repornire
total_commit_ms - suma tuturor timpilor de comitere a tranzacțiilor

exclusive_operation: (RO, începând cu: 5.10)
Afișează operația exclusivă în curs de execuție. Consultați secțiunea OPERAȚII EXCLUSIVE ALE SISTEMULUI DE FIȘIERE pentru detalii.
generation: (RO, începând cu: 5.11)
Afișează generația sistemului de fișiere montat.
label: (RW, începând cu: 3.14)
Afișează eticheta curentă a sistemului de fișiere montat.
metadata_uuid: (RO, începând cu: 5.0)
Afișează metadatele UUID ale sistemului de fișiere montat. Vedeți caracteristica metadata_uuid pentru mai multe detalii.
nodesize: (RO, începând cu: 3.14)
Afișează dimensiunea nodului sistemului de fișiere montat.
quota_override: (RW, începând cu: 4.13)
Afișează starea actuală a depășirii cotei. 0 înseamnă că nu există depășire a cotei. 1 înseamnă depășire a cotei, cota poate ignora configurările limită existente.
read_policy: (RW, începând cu: 5.11)
Afișează politica actuală de echilibrare pentru citiri. În prezent, este acceptat doar pid (echilibrare folosind valoarea ID-ului procesului (pid)). Mai multe politici de echilibrare sunt disponibile în versiunea experimentală, și anume round-robin.
sectorsize: (RO, începând cu: 3.14)
Afișează dimensiunea sectorului sistemului de fișiere montat.
temp_fsid: (RO, începând cu: 6.7)
Indică faptul că acest sistem de fișiere a primit un FSID temporar în momentul montării, făcând posibilă montarea dispozitivelor cu același FSID.

UUID/allocations¶

Fișierele și directoarele din directorul /sys/fs/btrfs/<UUID>/allocations sunt:

global_rsv_reserved: (RO, începând cu: 3.14)
Octeții utilizați din reserva globală.
global_rsv_size: (RO, începând cu: 3.14)
Dimensiunea totală a rezervării globale.
data/, metadata/ și system/ directoare: (RO, începând cu: 5.14)
Informații despre spațiu pentru cele 3 tipuri de grupuri de blocuri.

UUID/allocations/{data,metadata,system}¶

Fișierele din directorul /sys/fs/btrfs/<UUID>/allocations/data,metadata,system sunt:

bg_reclaim_threshold

(RW, începând cu: 5.19)

Procentul de spațiu recuperabil din dimensiunea grupului de blocuri (excluzând spațiul inutilizabil permanent) pentru a recupera grupul de blocuri. Poate fi utilizat pe dispozitive obișnuite sau de cele împărțite în zone (zoned).

bytes_*

(RO)

Valorile structurilor de date corespunzătoare pentru tipul și profilul grupului de blocuri dat, care sunt utilizate intern și se pot modifica rapid în funcție de sarcină.

Lista completă: bytes_may_use, bytes_pinned, bytes_readonly, bytes_reserved, bytes_used, bytes_zone_unusable

chunk_size

(RW, începând cu: 6.0)

Afișează dimensiunea bucății. Poate fi modificată pentru date și metadate (în mod independent) și nu poate fi definită pentru tipul de grup de blocuri de sistem. Nu poate fi definită pentru dispozitivele împărțite în zone, deoarece depinde de dimensiunea fixă a zonei dispozitivului. Limita superioară este de 10% din dimensiunea sistemului de fișiere; valoarea trebuie să fie un multiplu de 256 Mio și mai mare decât 0.

size_classes

(RO, începând cu: 6.3)

Numărul de grupuri de blocuri dintr-o anumită clasă, pe baza unor metode euristice care măsoară lungimea, vechimea și fragmentarea.

none 136
small 374
medium 282
large 93

UUID/bdi¶

Legătură simbolică către directorul sysfs al informațiilor despre dispozitivul de rezervă (BDI), care este legat de procesul și infrastructura de scriere înapoi (rescriere).

UUID/devices¶

Fișierele din directorul /sys/fs/btrfs/<UUID>/devices sunt legături simbolice denumite după nodurile dispozitivelor (de exemplu, sda, dm-0) și care indică directorul sysfs al acestora.

UUID/devinfo¶

Directorul conține subdirectoare denumite după ID-urile dispozitivelor (valori numerice). Fiecare subdirector conține informații despre dispozitivul cu ID-ul devid.

UUID/devinfo/ID_DISPOZITIV¶

Fișierele din directorul /sys/fs/btrfs/<UUID>/devinfo/<DEVID> sunt:

error_stats:: (RO, începând cu: 5.14)
Afișează statisticile acestui dispozitiv, la fel ca btrfs device stats (btrfs-device(8)).

write_errs 0
read_errs 0
flush_errs 0
corruption_errs 0
generation_errs 0

fsid:: (RO, începând cu: 5.17)
Afișează fsid-ul căruia îi aparține dispozitivul. Poate fi diferit de UUID dacă este un dispozitiv sămânță.
in_fs_metadata: (RO, începând cu: 5.6)
Afișează dacă s-a găsit dispozitivul. Ar trebui să fie întotdeauna 1, deoarece dacă valoarea devine 0, directorul DEVID va fi șters automat.
missing: (RO, începând cu: 5.6)
Afișează dacă dispozitivul este considerat lipsă de modulul nucleului.
replace_target: (RO, începând cu: 5.6)
Afișează dacă dispozitivul este ținta înlocuirii. Dacă nu se execută nicio înlocuire a dispozitivului, această valoare este 0.
scrub_speed_max: (RW, începând cu: 5.14)
Afișează limita de viteză a operației „scrub” pentru acest dispozitiv. Unitatea este octeți/s. 0 înseamnă nicio limită. Valoarea poate fi definită, dar nu este persistentă.
writeable: (RO, începând cu: 5.6)
Afișează dacă dispozitivul este inscriptibil.

UUID/qgroups¶

Fișierele din directorul /sys/fs/btrfs/<UUID>/qgroups/ sunt:

enabled

(RO, începând cu: 6.1)

Afișează dacă qgroup este activat. De asemenea, dacă qgroup este dezactivat, directorul qgroups va fi eliminat automat.

inconsistent

(RO, începând cu: 6.1)

Afișează dacă numerele qgroup sunt inconsistente. Dacă valoarea este 1, se recomandă efectuarea unei noi scanări qgroup.

drop_subtree_threshold

(RW, începând cu: 6.1)

Afișează pragul de eliminare a subarborelui pentru a marca automat qgroup ca fiind inconsistent.

Atunci când se elimină sub-volume mari cu funcția qgroup activată, se generează o sarcină foarte mare pentru contabilitatea qgroup. Dacă avem un sub-arbore al cărui nivel este mai mare sau egal cu această valoare, nu vom declanșa deloc contabilitatea qgroup, ci vom marca qgroup ca fiind inconsistent pentru a evita sarcina de lucru foarte mare.

Valoarea implicită este 3, ceea ce înseamnă că arborii de înălțime mică vor fi luați în considerare în mod corespunzător, deoarece acest lucru este suficient de rapid. Valoarea a fost 8 până la versiunea 6.13, în care nicio scădere a subarborelui nu poate declanșa reanalizarea qgroup, ceea ce o face mai puțin utilă.

O valoare mai mică poate reduce volumul de lucru al qgroup, cu prețul unei reanalizări suplimentare a qgroup pentru recalcularea numerelor.

UUID/qgroups/ID_NIVEL¶

Fișierele din fiecare director /sys/fs/btrfs/<UUID>/qgroups/<LEVEL>_<ID>/ sunt:

exclusive: (RO, începând cu: 5.9)
Afișează octeții deținuți exclusiv de qgroup.
limit_flags: (RO, începând cu: 5.9)
Afișează valoarea numerică a fanionelor de limită. Dacă este 0, înseamnă că nu este implicată nicio limită.
max_exclusive: (RO, începând cu: 5.9)
Afișează limitele privind octeții deținuți exclusiv.
max_referenced: (RO, începând cu: 5.9)
Afișează limitele de octeți la care se poate face referire.
referenced: (RO, începând cu: 5.9)
Afișează octeții la care se face referire ai qgroup.
rsv_data: (RO, începând cu: 5.9)
Afișează octeții rezervați pentru date.
rsv_meta_pertrans: (RO, începând cu: 5.9)
Afișează octeții rezervați pentru metadatele per tranzacție.
rsv_meta_prealloc: (RO, începând cu: 5.9)
Afișează octeții rezervați pentru metadatele prealocate.

UUID/discard¶

Fișierele din directorul /sys/fs/btrfs/<UUID>/discard/ sunt:

discardable_bytes: (RO, începând cu: 6.1)
Arată cantitatea de octeți care pot fi eliminați în modul asincron discard și nodiscard.
discardable_extents: (RO, începând cu: 6.1)
Afișează numărul de extinderi (extents) care urmează să fie eliminate în modul async discard și nodiscard.
discard_bitmap_bytes: (RO, începând cu: 6.1)
Afișează cantitatea de octeți eliminați din datele urmărite ca bitmaps.
discard_extent_bytes: (RO, începând cu: 6.1)
Afișează cantitatea de extinderi (extents) eliminate din datele urmărite ca bitmaps.
discard_bytes_saved: (RO, începând cu: 6.1)
Afișează cantitatea de octeți care au fost realocați fără a fi eliminați.
kbps_limit: (RW, începând cu: 6.1)
Limita reglabilă de kiloocteți pe secundă emisă ca IO discard în modul async discard.
iops_limit: (RW, începând cu: 6.1)
Limita reglabilă a numărului de operații de IO discard care urmează să fie emise în modul asincron discard.
max_discard_size: (RW, începând cu: 6.1)
Limită reglabilă pentru dimensiunea unei cereri de IO discard.

OPERAȚII EXCLUSIVE ALE SISTEMULUI DE FIȘIERE¶

Există mai multe operații care afectează întregul sistem de fișiere și nu pot fi rulate în paralel. Încercarea de a porni una în timp ce alta este în curs de execuție va eșua (vedeți excepțiile de mai jos).

Începând cu nucleul 5.10, operația care rulează în prezent poate fi obținută din /sys/fs/UUID/exclusive_operation cu următoarele valori și operații:

balance
balance paused (începând cu versiunea 5.17)
device add
device delete
device replace
resize
swapfile activate
none

Înscrierea în coadă este acceptată pentru mai multe sub-comenzi btrfs, astfel încât acestea să poată fi lansate simultan și apoi serializate.

Există o excepție atunci când o echilibrare pusă în pauză permite începerea unei operații de adăugare a unui dispozitiv, deoarece acestea nu se ciocnesc cu adevărat și acest lucru poate fi folosit pentru a adăuga mai mult spațiu pentru ca echilibrarea să se încheie.

LIMITE ALE SISTEMULUI DE FIȘIERE¶

maximum file name length: 255
Această limită este impusă de Linux VFS, structurile BTRFS putând stoca nume de fișiere mai mari.
maximum symlink target length: depinde de valoarea nodesize, pentru 4KiB este 3949 bytes, pentru nodesize mai mari este 4095 datorită limitei sistemului PATH_MAX
Ținta legăturii simbolice poate să nu fie o rută validă, adică componentele numelui rutei pot depăși limitele (NAME_MAX), nu există validarea conținutului la creare symlink(3).
maximum number of inodes: 264 dar depinde de spațiul disponibil pentru metadate deoarece nodurile-i sunt create dinamic
Fiecare sub-volum este un spațiu de nume independent de noduri-i și, prin urmare de numărul acestora, astfel încât limita este pentru fiecare sub-volum, nu pentru întregul sistem de fișiere.
inode numbers: număr minim: 256 (pentru subvolume), fișiere și directoare obișnuite: 257, număr maxim: (264 - 256)
Numerele de noduri-i care pot fi atribuite fișierelor create de utilizator provin din întregul spațiu de 64 de biți, cu excepția primelor 256 și a ultimelor 256 din acest interval, care sunt rezervate pentru identificatorii interni ai b-tree.
maximum file length: limita inerentă a BTRFS este 264 (16 Eio), dar limita practică a Linux VFS este 263 (8 Eio)
maximum number of subvolumes: id-urile sub-volumelor pot ajunge până la 248, dar numărul sub-volumelor reale depinde de spațiul disponibil pentru metadate
Spațiul consumat de toate metadatele sub-volumului, inclusiv evidența extinderilor partajate, poate fi mare (Mio, Gio). Intervalul nu este întreg intervalul de 64 de biți din cauza qgroups care utilizează cei 16 biți superiori în alte scopuri.
maximum number of hardlinks of a file in a directory: 65536 atunci când funcția extref este activată în timpul mkfs (implicit), aproximativ 100 în caz contrar și depinde de lungimea numelui de fișier care se potrivește într-un nod de metadate
minimum filesystem size: dimensiunea minimă a fiecărui dispozitiv depinde de caracteristica mixed-bg, fără aceasta (implicit) este de aproximativ 109Mio, cu mixed-bg este de 16Mio

SUPORT PENTRU ÎNCĂRCĂTORUL DE PORNIRE¶

GRUB2 (https://www.gnu.org/software/grub) are cel mai avansat suport pentru pornirea de pe BTRFS în ceea ce privește caracteristicile.

U-Boot (https://www.denx.de/wiki/U-Boot/) oferă suport decent pentru pornire, dar nu toate funcțiile BTRFS sunt implementate. Consultați documentația.

În general, primul 1 Mio de pe fiecare dispozitiv rămâne nefolosit, cu excepția superblocului primar, care se află la o poziție de 64 KiB și ocupă 4 KiB. Restul spațiului poate fi utilizat în mod liber de către încărcătoarele de sistem sau pentru alte informații de sistem. Rețineți că pornirea de pe un sistem de fișiere de pe un dispozitiv împărțit în zone zoned device nu este acceptată.

ATRIBUTELE FIȘIERELOR¶

Sistemul de fișiere btrfs acceptă configurarea atributelor sau fanioanelor fișierelor. Rețineți că există interfețe vechi și noi, cu denumiri confuze. Lista următoare ar trebui să clarifice acest aspect:

atribute: chattr(1) sau lsattr (1) (ioctl-urile sunt FS_IOC_GETFLAGS și FS_IOC_SETFLAGS), datorită numelor ioctl, atributele sunt numite și fanioane
xflags: pentru a se distinge de cele anterioare, acestea sunt fanioane extinse, cu biți configurabili similari atributelor, dar extensibile, iar în viitor vor fi adăugați biți noi (comenzile ioctl sunt FS_IOC_FSGETXATTR și FS_IOC_FSSETXATTR, dar nu au legătură cu atributele extinse, denumite și xattrs), nu există un instrument standard pentru a modifica biții, există suport în xfs_io(8) ca comandă xfs_io -c chattr

Atributele au constrângeri asociate și nu toate combinațiile pot fi utilizate, ordinea în care sunt definite fiind, de asemenea, importantă. Majoritatea atributelor se aplică fișierelor și directoarelor, dar semantica lor poate varia. În cazul directoarelor, un atribut poate însemna doar că acesta se aplică tuturor fișierelor noi (inheritable în lista de mai jos). Unele atribute necesită drepturi de administrator pentru a fi definite.

Atribute¶

a

(fișier, director, rădăcină) append only, noile scrieri sunt întotdeauna scrise la sfârșitul fișierului

A

(fișier, director) no atime updates

c

(fișier, director, moștenit) compress data, toate datele scrise după activarea acestui atribut vor fi comprimate. Vă rugăm să rețineți că comprimarea este afectată și de opțiunile de montare sau de atributele directorului părinte.

Atunci când este definit pe un director, toate fișierele nou create vor moșteni acest atribut. Acest atribut nu poate fi definit în același timp cu 'm'.

C

(fișier, director, moștenit) no copy-on-write, modificările datelor din fișiere sunt efectuate pe loc (direct)

Când este definit pentru un director, toate fișierele nou create vor moșteni acest atribut.

NOTĂ:

Din cauza limitărilor de implementare, acest fanion poate fi activat/dezactivat numai pentru fișierele goale.

d: (fișier) no dump, are sens cu instrumente terțe precum dump(8), pe BTRFS atributul poate fi activat/dezactivat, dar nu se fac alte manipulări speciale
D: (director) synchronous directory updates, pentru mai multe detalii căutați open(2) pentru O_SYNC și O_DSYNC
i: (fișier, director, root) immutable, nicio modificare a datelor și metadatelor fișierelor nu este permisă nici măcar utilizatorului root atâta timp cât acest atribut este activat (evident, excepția este dezactivarea atributului)
m: (fișier, director) fără compresie, dezactivează definitiv comprimarea fișierului specificat. Opțiunile de montare referitoare la compresie nu vor afecta acest fișier. (chattr(1) suport adăugat în versiunea 1.46.2)
Atunci când este definit pentru un director, toate fișierele nou create vor moșteni acest atribut. Acest atribut nu poate fi definit în același timp cu c.
S: (fișier) synchronous updates, pentru mai multe detalii căutați open(2) pentru O_SYNC și O_DSYNC
V: (fișier, numai-citire) fs-verity enabled pe fișier

Nu sunt acceptate alte atribute. Pentru lista completă, consultați pagina manualului chattr(1).

XFLAGS¶

Există o suprapunere a literelor atribuite biților cu atributele, această listă se referă la ceea ce oferă xfs_io(8):

i: immutable, la fel ca atributul
a: append only, la fel ca atributul
s: synchronous updates, la fel ca atributul S
A: no atime updates, la fel ca atributul
d: no dump, la fel ca atributul

MODUL „ZONED” (de împărțire în zone)¶

Începând cu versiunea 5.12, btrfs acceptă așa-numitul „mod zonal” zoned mode. Acesta reprezintă un format special pe disc și o strategie de alocare/scriere compatibilă cu dispozitivele împărțite în zone. Pe scurt, un dispozitiv este împărțit în zone de dimensiuni fixe, iar fiecare zonă poate fi actualizată prin adăugare-doar (append-only) sau reinițializată. Deoarece btrfs nu are structuri de date fixe, cu excepția super-blocurilor, „modul zonal” necesită doar plasarea blocurilor care respectă constrângerile dispozitivului. Puteți afla mai multe despre întreaga arhitectură la https://zonedstorage.io .

Dispozitivele sunt denumite și SMR/ZBC/ZNS, în modul host-managed. Rețineți că există dispozitive care apar ca neîmpărțite în zone, dar care sunt de fapt de împărțite în zone. Acestea sunt drive-managed și utilizarea modului „zoned” (de împărțire în zone) nu va ajuta.

Dimensiunea zonei depinde de dispozitiv, dimensiunile tipice fiind de 256 Mio sau 1 Gio. În general, trebuie să fie o putere a lui doi. Dispozitivele emulate cu zone, precum null_blk, permit definirea diverselor dimensiuni ale zonei.

Cerințe, limitări¶

toate dispozitivele trebuie să aibă aceeași dimensiune a zonei
dimensiunea maximă a zonei este de 8 Gio
dimensiunea minimă a zonei este de 4 Mio
amestecarea dispozitivelor împărțite în zone și a celor neîmpărțite în zone este posibilă, scrierile zonale sunt emulate, dar acest lucru este în special pentru testare
super-blocul este tratat într-un mod special și se află în locații diferite față de un sistem de fișiere neîmpărțit în zone:

primar: 0octeți (și următoarele două zone)
secundar: 512 Gio (și următoarele două zone)
terțiar: 4 Tio (4096 Gio și următoarele două zone)

Caracteristici incompatibile¶

Principala constrângere a dispozitivelor împărțite în zone este lipsa actualizării pe loc(direct) a datelor. Acest lucru este intrinsec incompatibil cu anumite caracteristici:

NODATACOW - suprascriere pe loc (directă), nu se pot crea astfel de fișiere
fallocate - prealocarea spațiului pentru prima scriere pe loc (directă)
mixed-bg - scrieri neordonate în date și metadate, remedierea acestei probleme implică utilizarea unor grupuri separate de blocuri de date și metadate
booting - zona la poziția 0 conține super-blocul, reinițializarea zonei ar distruge datele încărcătorului de pornire

Suportul inițial nu dispune de anumite funcții, dar acestea sunt planificate:

este acceptat numai profilul unic (date, metadate) și DUP (metadate)
fstrim - din cauza dependenței de cache-ul spațiului liber v1

Super-bloc¶

După cum s-a menționat mai sus, super-blocul este tratat într-un mod special. Pentru a asigura protecția împotriva erorilor, cel puțin o zonă dintr-o locație cunoscută trebuie să conțină un super-bloc valid. Aceasta este implementată sub forma unui tampon circular în două zone consecutive, începând de la pozițiile cunoscute 0B (0 octeți), 512 Gio și 4 Tio.

Valorile sunt diferite față de cele de pe dispozitivele fără zone. Fiecare super-bloc nou este adăugat la sfârșitul zonei; odată ce aceasta este completă, zona este reinițializară, iar operațiile de scriere continuă în următoarea zonă. Pentru a identifica cel mai recent super-bloc, este necesar să se citească pozițiile ambelor zone și să se determine ultima versiune scrisă.

Spațiul rezervat pentru super-bloc depinde de dimensiunea zonei. Copiile secundare și terțiare sunt amplasate la distanțe mari, întrucât se preconizează că dispozitivele vor avea o capacitate mare, de ordinul zecilor de teraocteți. Dimensiunea maximă acceptată a zonei este de 8 Gio, ceea ce ar însemna că, de exemplu, intervalul 0-16 Gio ar fi rezervat exclusiv pentru super-bloc pe un dispozitiv ipotetic cu această dimensiune a zonei. Aceasta reprezintă o risipă, dar este necesară pentru a garanta siguranța în caz de colaps.

Recuperarea zonei, colectarea gunoiului¶

Deoarece zonele sunt de tip „append-only” -- doar-adăugare, suprascrierea datelor sau modificările COW din metadate fac ca anumite părți ale zonelor să fie utilizate, dar fără a fi conectate la structurile sistemului de fișiere. Acest lucru face ca spațiul să devină inutilizabil și să crească în timp. Odată ce raportul atinge un prag (configurabil), se inițiază un proces de recuperare în fundal care realocă blocurile rămase în uz într-o zonă nouă. Zona veche este reinițializară și poate fi utilizată din nou.

Acest proces poate dura ceva timp, în funcție de alte operații din fundal sau de cantitatea de date noi scrise. Este posibil să se producă o eroare ENOSPC intermitentă. Unele dispozitive limitează, de asemenea, numărul de zone active.

Dispozitive¶

Hardware real¶

Seria WD Ultrastar 600 promovează HM-SMR, adică modul de împărțire în zone gestionat de gazdă. Mai există încă două moduri: DA (gestionat de dispozitiv, fără exportarea informațiilor de împărțire în zone către sistem) și HA (compatibil cu gazda, poate fi utilizat ca un disc obișnuit, dar scrierile zonele împărțite îmbunătățesc performanța). În prezent nu sunt disponibile multe dispozitive, iar informațiile despre modul de împărțire în zone, exact sunt greu de găsit; verificați fișele tehnice sau sursele comunității care colectează informații de la dispozitive reale.

Notă: modul de împărțire în zone nu funcționează cu discurile DM-SMR.

•: SSD Ultrastar® DC ZN540 NVMe ZNS (product brief)

Emulat: null_blk¶

Controlorul null_blk oferă un dispozitiv bazat pe memorie și este potrivit pentru testare. Configurarea dispozitivelor prezintă câteva particularități. Modulul trebuie încărcat cu nr_devices=0, altfel numerotarea nodurilor de dispozitiv va fi decalată. configfs trebuie montat la /sys/kernel/config, iar administrarea dispozitivelor null_blk se face în /sys/kernel/config/nullb. Nodurile dispozitivelor sunt denumite precum dev/nullb0 și sunt numerotate secvențial. NOTĂ: numele dispozitivului poate fi diferit de numele directorului din sysfs!

Configurarea:

modprobe configfs
modprobe null_blk nr_devices=0

Creați un dispozitiv mydev, presupunând că nu există alte dispozitive create anterior, cu dimensiunea de 2048 Mio și dimensiunea zonei de 256 Mio. Există mai mulți parametri reglabili, acesta fiind un exemplu minim care utilizează valorile implicite:

cd /sys/kernel/config/nullb/
mkdir mydev
cd mydev
echo 2048 > size
echo 1 > zoned
echo 1 > memory_backed
echo 256 > zone_size
echo 1 > power

Aceasta va crea un dispozitiv /dev/nullb0, iar valoarea fișierului index va corespunde numărului final al nodului dispozitivului.

Eliminați dispozitivul:

rmdir /sys/kernel/config/nullb/mydev

Apoi continuați cu mkfs.btrfs /dev/nullb0, modul de împărțire în zone fiind detectat automat.

Pentru comoditate, există un script care încorporează operațiile de bază de gestionare null_blk https://github.com/kdave/nullb.git, comenzile de mai sus devin:

nullb setup
nullb create -s 2g -z 256
mkfs.btrfs /dev/nullb0
...
nullb rm nullb0

Emulat: runner (executor) TCMU¶

TCMU este un cadru de lucru pentru emularea dispozitivelor SCSI în spațiul utilizatorului, oferind diverse sisteme pentru stocare, precum și suport pentru împărțirea în zone. Un dispozitiv cu zone bazat pe fișiere poate oferi mai multe opțiuni pentru spații de stocare și dimensiuni ale zonelor mai mari. Vă rugăm să urmați instrucțiunile de la

Compatibilitate, incompatibilitate¶

caracteristica stabilește un bit incompat și necesită un nou nucleu pentru a accesa sistemul de fișiere (atât pentru citire, cât și pentru scriere)
super-blocul trebuie tratat într-un mod special; există tot trei copii, dar la distanțe diferite (0, 512 Gio, 4 Tio), iar cele două zone consecutive formează un tampon inelar al super-blocurilor; pentru a găsi pe cel mai recent, este necesar să-l citim de la indicatorul de scriere sau să efectuăm o scanare completă a zonelor
amestecarea dispozitivelor împărțite în zone și a celor neîmpărțite în zone este posibilă, (zonele sunt emulate), dar acest lucru este recomandat doar pentru testare
amestecarea dispozitivelor împărțite în zone cu diferite dimensiuni ale zonelor, nu este posibilă
dimensiunile zonelor trebuie să fie puteri de doi, dimensiunile zonelor dispozitivelor reale sunt, de exemplu, 256Mio sau 1Gio, se așteaptă dimensiuni mai mari, dimensiunea maximă a zonelor acceptate de btrfs este 8Gio

Stare, stabilitate, raportarea erorilor¶

Modul de împărțire în zone (zoned) a fost publicat în versiunea 5.12 și mai există încă unele imperfecțiuni și cazuri speciale care pot apărea în timpul testării. Vă rugăm să raportați erorile la https://github.com/naota/linux/issues/ .

Referințe¶

•: https://zonedstorage.io

https://zonedstorage.io/projects/libzbc/ -- libzbc is library and set of tools to directly manipulate devices with ZBC/ZAC support
https://zonedstorage.io/projects/libzbd/ -- libzbd uses the kernel provided zoned block device interface based on the ioctl() system calls

https://hddscan.com/blog/2020/hdd-wd-smr.html -- some details about exact device types
https://lwn.net/Articles/853308/ -- Btrfs on zoned block devices
https://www.usenix.org/conference/vault20/presentation/bjorling -- Zone Append: A New Way of Writing to Zoned Storage

DISPOZITIV DE CONTROL¶

Există un dispozitiv special de caractere /dev/btrfs-control cu numerele majore și minore 10 și 234 (dispozitivul poate fi găsit în categoria misc).

$ ls -l /dev/btrfs-control
crw------- 1 root root 10, 234 Jan  1 12:00 /dev/btrfs-control

Dispozitivul acceptă unele apeluri ioctl care pot efectua următoarele acțiuni pe modulul sistemului de fișiere:

scanarea dispozitivelor pentru sistemul de fișiere btrfs (de exemplu, pentru a permite montarea automată a sistemelor de fișiere cu mai multe dispozitive) și înregistrarea acestora cu modulul nucleului
similar cu scanarea, dar așteaptă, de asemenea, până când procesul de scanare a dispozitivului este finalizat pentru un sistem de fișiere specificat
obține caracteristicile acceptate (pot fi găsite și sub /sys/fs/btrfs/features)

Dispozitivul este creat la inițializarea sistemului de fișiere btrfs, fie ca modul, fie ca funcționalitate integrată, și are sens doar în acest context. Dacă se execută, de exemplu, comanda mkfs fără ca modulul să fie încărcat, dispozitivul nu va fi înregistrat și probabil va apărea un mesaj de avertizare în acest sens.

În cazuri rare, când modulul este încărcat, dar dispozitivul nu este prezent (cel mai probabil șters accidental), este posibil să îl recreați prin

# mknod --mode=600 /dev/btrfs-control c 10 234

sau (începând cu versiunea 5.11) printr-o comandă convenabilă

# btrfs rescue create-control-device

Dispozitivul de control nu este strict necesar, însă scanarea dispozitivelor nu va funcționa și va fi necesară utilizarea unei soluții alternative pentru montarea unui sistem de fișiere cu mai multe dispozitive. Opțiunea de montare dispozitiv poate declanșa scanarea dispozitivelor în timpul montării; a se vedea de asemenea btrfs device scan.

SISTEM DE FIȘIERE CU PROFILURI MULTIPLE¶

Este posibil ca un sistem de fișiere Btrfs să conțină mai multe profiluri de grupuri de blocuri de același tip. Această situație poate apărea atunci când o conversie a profilului care utilizează filtre de echilibrare este întreruptă (vezi btrfs-balance(8)). Anumite comenzi btrfs efectuează un test pentru a detecta acest tip de situație și afișează un mesaj de avertizare asemănător cu acesta:

WARNING: Multiple block group profiles detected, see 'man btrfs(5)'.
WARNING:   Data: single, raid1
WARNING:   Metadata: single, raid1

Rezultatul corespunzător al btrfs filesystem df ar putea arăta astfel:

WARNING: Multiple block group profiles detected, see 'man btrfs(5)'.
WARNING:   Data: single, raid1
WARNING:   Metadata: single, raid1
Data, RAID1: total=832.00MiB, used=0.00B
Data, single: total=1.63GiB, used=0.00B
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=8.00MiB, used=112.00KiB
Metadata, RAID1: total=64.00MiB, used=32.00KiB
GlobalReserve, single: total=16.25MiB, used=0.00B

Există mai mult de o linie pentru tipurile Data și Metadata, în timp ce profilurile sunt single și RAID1.

Această stare a sistemului de fișiere este OK, dar cel mai probabil este nevoie ca utilizatorul/administratorul să întreprindă o acțiune și să finalizeze sarcinile întrerupte. Acest lucru nu poate fi făcut cu ușurință în mod automat, de asemenea, utilizatorul cunoaște profilurile finale așteptate.

În exemplul de mai sus, sistemul de fișiere a pornit ca un singur dispozitiv cu profilul de grup de blocuri single. Apoi a fost adăugat un alt dispozitiv, urmat de o operație de echilibrare cu convert=raid1, dar, din anumite motive, aceasta nu s-a finalizat. Reluarea operației de echilibrare cu convert=raid1 va continua și va avea ca rezultat un sistem de fișiere în care toate profilurile grupurilor de blocuri vor fi RAID1.

NOTĂ:

Dacă sunteți familiarizați cu filtrele de echilibrare, puteți folosi comanda convert=raid1,profiles=single,soft, care va prelua doar profilele single neconvertite și le va transforma în raid1. Acest lucru poate accelera procesul de conversie, întrucât nu se va încerca rescrierea profilelor raid1 deja convertite.

Este recomandabil să existe un singur profil, deoarece acesta definește în mod clar profilul grupurilor de blocuri nou alocate; în caz contrar, acest lucru depinde de politica internă de alocare. Atunci când există mai multe profiluri, ordinea de selecție este RAID56, RAID10, RAID1, RAID0, cu condiția ca restricțiile privind numărul dispozitivelor să fie respectate.

Comenzile care afișează avertismentul au fost alese astfel încât să atragă atenția utilizatorului atunci când starea sistemului de fișiere este modificată în acest sens. Acestea sunt: device add, device delete, balance cancel, balance pause. Comenzi care afișează informații despre utilizarea spațiului: filesystem df, device usage. Comanda filesystem usage afișează o linie în rezumatul general:

Multiple profiles:                 yes (data, metadata)

DISPOZITIV DE ÎNSĂMÂNȚARE¶

Mecanismul COW și prezența mai multor dispozitive sub o singură carcasă fac posibil un concept interesant, numit „dispozitiv de inițializare”: extinderea unui sistem de fișiere de tip „read-only” de pe un dispozitiv cu ajutorul unui alt dispozitiv care înregistrează toate operațiile de scriere. De exemplu, imaginați-vă o imagine de referință imuabilă a unui sistem de operare îmbunătățită cu un alt dispozitiv care permite utilizarea datelor din imaginea de referință și funcționarea normală. Această idee a apărut inițial pe CD-ROM-urile cu sistem de operare de bază și permitea utilizarea acestora pentru sisteme live, dar a devenit învechită. Există tehnologii care oferă funcționalități similare, cum ar fi unionmount, overlayfs sau qcow2 instantanee de imagine.

Dispozitivul de însămânțare pornește ca un sistem de fișiere obișnuit; odată ce conținutul este pregătit, se utilizează comanda btrfstune -S 1 pentru a-l marca ca dispozitiv de însămânțare. Montarea unui astfel de dispozitiv nu va permite nicio operație de scriere, cu excepția adăugării unui nou dispozitiv prin comanda btrfs device add. Apoi, sistemul de fișiere poate fi remontat în modul de citire-scriere.

Având în vedere că sistemul de fișiere de pe dispozitivul de însămânțare este întotdeauna recunoscut ca fiind doar pentru citire, acesta poate fi utilizat pentru a însămânța simultan mai multe sisteme de fișiere de pe un singur dispozitiv. UUID-ul asociat în mod obișnuit unui dispozitiv este schimbat automat într-un UUID aleatoriu la fiecare montare.

NOTĂ:

Înainte de versiunea 6.17 a nucleului, un dispozitiv semănător putea fi montat independent, alături de sistemele de fișiere create din acesta. Însă, începând cu versiunea 6.17 a nucleului, un dispozitiv semănător poate fi montat fie prin intermediul unui sistem de fișiere creat din acesta, fie direct ca dispozitiv semănător, dar nu în ambele moduri simultan.

Acest lucru este menit să asigure că un dispozitiv de blocuri are un singur sistem de fișiere legat de acesta, astfel încât evenimentele de lipsă a dispozitivului în timpul rulării să poată fi gestionate corespunzător.

Odată ce dispozitivul de însămânțare este montat, este necesar dispozitivul de scriere. După adăugarea acestuia, demontarea și remontarea cu comanda umount /ruta; mount /dev/de-scriere /ruta sau remontarea în mod citire-scriere cu comanda remount -o remount,rw face ca sistemul de fișiere de la /ruta să fie gata de utilizare.

NOTĂ:

A existat o eroare cunoscută cu utilizarea opâiunii „remount” pentru a face montarea inscriptibilă: „remount” va lăsa sistemul de fișiere într-o stare în care nu este capabil să curețe instantaneele șterse, astfel încât acesta va pierde spațiu până când este demontat și montat corect.

Această eroare a fost remediată în versiunile 5.11 și mai recente ale nucleului.

În plus, ștergerea dispozitivului de însămânțare din sistemul de fișiere îl poate transforma într-un sistem de fișiere normal, cu condiția ca dispozitivul inscriptibil să poată conține și toate datele din dispozitivul de însămânțare.

Fanionul dispozitivului de însămânțare poate fi dezactivat din nou cu comanda btrfstune -f -S 0, permițând astfel actualizarea cu date mai recente; totuși, rețineți că această operație va invalida toate sistemele de fișiere existente care utilizează acest dispozitiv de însămânțare. Această procedură este adecvată pentru anumite situații, dar nu și pentru altele, iar utilizarea fanionului de forțare în comandă este obligatorie pentru a evita erorile accidentale.

Exemplu de creare și utilizare a unui dispozitiv de însămânțare:

# mkfs.btrfs /dev/sda
# mount /dev/sda /mnt/mnt1
... fill mnt1 with data
# umount /mnt/mnt1
# btrfstune -S 1 /dev/sda
# mount /dev/sda /mnt/mnt1
# btrfs device add /dev/sdb /mnt/mnt1
# umount /mnt/mnt1
# mount /dev/sdb /mnt/mnt1
... /mnt/mnt1 este acum inscriptibilă

Acum /mnt/mnt1 poate fi utilizat în mod normal. Dispozitivul /dev/sda poate fi montat din nou cu un alt dispozitiv inscriptibil:

# mount /dev/sda /mnt/mnt2
# btrfs device add /dev/sdc /mnt/mnt2
# umount /mnt/mnt2
# mount /dev/sdc /mnt/mnt2
... /mnt/mnt2 este acum inscriptibilă

Dispozitivul inscriptibil (file:/dev/sdb) poate fi decuplat de dispozitivul de însămânțare și utilizat independent:

# btrfs device delete /dev/sda /mnt/mnt1

Deoarece conținutul provine din dispozitivul de însămânțare, este posibil să transformați /dev/sdb din nou într-un dispozitiv de însămânțare și să repetați întregul proces.

Câteva lucruri de reținut:

se recomandă utilizarea unui singur dispozitiv pentru dispozitivul de însămânțare, funcționează pentru mai multe dispozitive, dar profilul single trebuie utilizat pentru a face ca ștergerea dispozitivului de însămânțare să funcționeze
profilele grupurilor de blocuri single și dup oferă suport pentru cazurile de utilizare de mai sus
eticheta este copiată de la dispozitivul de însămânțare și poate fi modificată prin btrfs filesystem label
fiecare nouă montare a dispozitivului de însămânțare primește un nou UUID aleatoriu
Comanda umount /ruta; mount /dev/inscriptibil /ruta poate fi înlocuită cu mount -o remount,rw /ruta, dar aceasta nu va elibera spațiul sub-volumelor șterse până când dispozitivul de însămânțare nu este montat din nou în mod citire-scriere, înainte de efectuarea din nou a operației de însămânțare

Dispozitive de însămânțare în lanț¶

Deși nu este recomandat și reprezintă mai degrabă un scenariu de utilizare puțin cunoscut și netestat, este posibilă conectarea în serie a dispozitivelor de însămânțare. În primul exemplu, dispozitivul inscriptibil /dev/sdb poate fi transformat din nou într-un alt dispozitiv de însămânțare, în funcție de dispozitivul de însămânțare neschimbat /dev/sda. Apoi, folosind /dev/sdb ca dispozitiv principal de însămânțare, acesta poate fi extins cu un alt dispozitiv inscriptibil, să zicem /dev/sdd, și continuă ca mai înainte ca o structură simplă arborescentă pe dispozitive.

# mkfs.btrfs /dev/sda
# mount /dev/sda /mnt/mnt1
... fill mnt1 with data
# umount /mnt/mnt1
# btrfstune -S 1 /dev/sda
# mount /dev/sda /mnt/mnt1
# btrfs device add /dev/sdb /mnt/mnt1
# mount -o remount,rw /mnt/mnt1
... /mnt/mnt1 este acum inscriptibilă
# umount /mnt/mnt1
# btrfstune -S 1 /dev/sdb
# mount /dev/sdb /mnt/mnt1
# btrfs device add /dev/sdc /mnt
# mount -o remount,rw /mnt/mnt1
... /mnt/mnt1 este acum inscriptibilă
# umount /mnt/mnt1

Ca rezultat, avem:

sda este un singur dispozitiv de însămânțare, cu conținutul său inițial
sdb este un dispozitiv de însămânțare, dar necesită sda, conținutul este din momentul în care sdb este făcut însămânțare, adică conținutul lui sda cu orice modificări ulterioare
sdc ultimul inscriptibil, poate fi transformat într-unul de însămânțare la fel cum a fost sdb, păstrându-i conținutul și depinzând de sda și sdb

Atât timp cât dispozitivele de însămânțare sunt nemodificate și disponibile, acestea pot fi utilizate pentru a crea o altă ramură.

STAREA RAID56 ȘI PRACTICI RECOMANDATE¶

Funcția RAID56 asigură distribuirea datelor și paritatea pe mai multe dispozitive, la fel ca în cazul sistemelor tradiționale RAID5/6. Există însă unele deficiențe de implementare și proiectare care o fac nesigură în anumite situații extreme, iar această funcție nu ar trebui utilizată în mediul de producție, ci doar în scopuri de evaluare sau testare. Protecția metadatelor în caz de întrerupere a alimentării cu energie electrică nu este garantată 100% în cazul RAID56.

Metadate¶

Nu utilizați raid5 sau raid6 pentru metadate. Utilizați raid1 sau, respectiv, raid1c3.

Profilele de rezervă oferă aceleași garanții împotriva pierderii unuia sau a două dispozitive și, în anumite privințe, pot reprezenta o îmbunătățire. Recuperarea datelor în cazul pierderii unui singur dispozitiv va necesita doar accesarea primei sau a celei de-a doua copii rămase, care, în general, poate fi stocată pe alte dispozitive datorită modului în care funcționează RAID1 pe btrfs, spre deosebire de un profil de tip „striped” (similar cu raid0), care ar necesita prezența tuturor dispozitivelor în permanență.

Modelul de alocare a spațiului și consumul diferă (de exemplu, pe N dispozitive): în cazul raid5, de exemplu, pe fiecare dispozitiv este rezervat un bloc de 1 Gio, în timp ce în cazul raid1 fiecare bloc de 1 Gio este stocat pe două dispozitive. Consumul fiecărui 1 Gio de metadate utilizate este atunci N * 1 Gio față de 2 * 1 Gio. Utilizarea raid1 este, de asemenea, mai convenabilă pentru echilibrare/conversie la un alt profil, datorită cerințelor mai reduse privind spațiul disponibil pentru blocuri.

Suport lipsă/incomplet¶

Atunci când RAID56 se află pe același sistem de fișiere cu profiluri RAID diferite, raportarea spațiului este inexactă, de exemplu df, btrfs filesystem df sau btrfs filesystem usage. Atunci când există un singur profil pentru fiecare tip de grup de blocuri (de exemplu, RAID5 pentru date), raportarea este exactă.

Atunci când se pornește procesul de curățare pe un sistem de fișiere RAID56, acesta se pornește pe toate dispozitivele, ceea ce duce la scăderea performanței. Soluția este să-l porniți separat pe fiecare dispozitiv. Din această cauză, statisticile dispozitivelor pot să nu corespundă cu starea reală, iar unele erori pot fi raportate de mai multe ori.

Problema „write hole”. O oprire necontrolată ar putea lăsa o bandă parțial scrisă într-o stare în care unele intervale ale benzii și paritatea provin din scrierile anterioare, iar altele sunt noi. Nu se ține evidența care informații sunt de un fel și care de altul. Jurnalul de scriere nu este implementat. O alternativă ar fi un ciclu complet de citire-modificare-scriere, care ar asigura scrierea întregii benzi, evitând complet problema „write hole”, dar performanța în acest caz s-a dovedit a fi prea slabă pentru a putea fi utilizată.

Împărțirea în benzi se realizează pe toate dispozitivele disponibile (la momentul alocării blocurilor), astfel încât, în cazul în care se adaugă un dispozitiv nou, acesta s-ar putea să nu fie utilizat imediat și ar fi necesară o reechilibrare. Nu este implementată o lățime fixă a benzii.

GLOSAR¶

Termenii care apar în cursivă apar și în acest glosar.

allocator: De obicei, allocator înseamnă alocatorul block, adică logica din interiorul sistemului de fișiere care decide unde să plaseze blocurile nou alocate pentru a menține mai multe constrângeri (precum amplasarea datelor, fragmentarea redusă).
În btrfs, alocatorul se poate referi și la alocatorul chunk, adică logica din spatele plasării bucăților pe dispozitive.
balance: O operație care poate fi efectuată asupra unui sistem de fișiere Btrfs, de exemplu prin comanda btrfs balance /path. O operație de echilibrare trece din nou toate datele din sistemul de fișiere prin alocator. Aceasta are ca scop principal reechilibrarea datelor din sistemul de fișiere între dispozitive atunci când se adaugă sau se elimină un dispozitiv. O operație de echilibrare va regenera copiile lipsă pentru nivelurile redundante RAID, în cazul în care un dispozitiv s-a defectat. Începând cu versiunea 3.3 a nucleului Linux, o operatie de echilibrare poate fi selectivă în ceea ce priveste părțile sistemului de fișiere care sunt rescrise folosind filtre filters.
barrier: O instrucțiune adresată hardware-ului subiacent pentru a se asigura că toate datele situate înaintea barierei sunt scrise fizic pe suportul de stocare permanent înaintea celor situate după aceasta. Se utilizează în cadrul abordării copy on write a sistemului de fișiere Btrfs pentru a asigura coerența sistemului de fișiere.
block: O singură piesă de stocare contiguă din punct de vedere fizic și logic pe un dispozitiv, de dimensiune, de exemplu, 4K. În unele contexte, se face referire și la sector, deși este preferat termenul block.
block group: Unitatea de alocare a spațiului în Btrfs. Un grup de blocuri este configurat pe disc de către alocatorul Btrfs și va consta dintr-unul sau mai multe chunks (fragmente), fiecare fiind stocat pe un dispozitiv diferit. Numărul de chunks-uri utilizate într-un grup de blocuri va depinde de nivelul său RAID.
B-tree: Structura fundamentală de stocare a datelor utilizată în btrfs. Cu excepția superblocurilor, toate metadatele btrfs sunt stocate într-unul dintre numeroșii arbori-B (B-trees) de pe disc. Arborii-B stochează perechi cheie/element. Deși se folosește același cod pentru implementarea tuturor arborilor-B, există câteva categorii diferite de arbori-B. Denumirea „btrfs” se referă la utilizarea arborilor-B.
btrfsck, fsck, btrfs-check: Instrument din pachetul btrfs-progs care verifică un sistem de fișiere nemontat (offline) și raportează eventualele erori identificate în structurile sistemului de fișiere. În mod implicit, instrumentul rulează în modul numai-citire, deoarece remedierea erorilor poate fi periculoasă. A se vedea de asemenea scrub.
btrfs-progs: Instrumente în modul utilizator pentru gestionarea funcționalităților specifice btrfs. Proiectul este întreținut la http://github.com/kdave/btrfs-progs.git . Interfața principală pentru funcțiile btrfs este instrumentul independent btrfs, deși și alte instrumente, precum mkfs.btrfs și btrfstune, fac parte din btrfs-progs.
chunk: O parte a unui block group. Bucățile au dimensiunea de 1 Gio (pentru date) sau 256 Mio (pentru metadata), în funcție de dimensiunea totală a sistemului de fișiere.
chunk tree: Un strat care păstrează informații despre corespondența dintre adresele blocurilor fizice și logice. Acesta este stocat în cadrul grupului system.
cleaner: Termenul este folosit de obicei în contextul subvolumelor șterse. Este vorba despre un proces care rulează în fundal și care elimină datele propriu-zise odată ce un subvolum a fost șters. Procesul de curățare poate implica o activitate intensă la nivel de operații de In/Ieș și CPU, în funcție de gradul de fragmentare și de cantitatea de date partajate cu alte subvolume.
Firul de execuție mai curat al nucleului procesează, de asemenea, defragmentarea declanșată de opțiunea de montare autodefrag, eliminarea grupurilor de blocuri goale și alte câteva sarcini de finalizare.
copy-on-write, COW: Cunoscută și sub denumirea de COW. Metoda utilizată de btrfs pentru modificarea datelor. În loc să suprascrie direct datele în locația inițială, btrfs realizează o copie a datelor, o modifică și apoi scrie datele modificate într-o altă locație (neutilizată) de pe disc. Apoi actualizează metadatele pentru a reflecta noua locație a datelor. Pentru a actualiza metadatele, blocurile de metadate afectate sunt tratate în același mod. În sistemele de fișiere COW, fișierele tind să se fragmenteze pe măsură ce sunt modificate. Metoda copy-on-write este utilizată și în implementarea snapshots și reflink copies. Un sistem de fișiere copy-on-write este, în teorie, întotdeauna consistent, cu condiția ca hardware-ul subiacent să accepte barriers.
default subvolume: sub-volumul dintr-un sistem de fișiere btrfs care este montat la montarea sistemului de fișiere fără a utiliza opțiunea de montare subvol=.
device: Un dispozitiv de blocuri Linux, de exemplu, un disc întreg, o partiție, un volum logic LVM, un dispozitiv loopback sau un dispozitiv de blocuri de rețea. Un sistem de fișiere btrfs poate rezida pe unul sau mai multe dispozitive.
df: Un instrument standard Unix pentru afișarea spațiului utilizat și liber dintr-un sistem de fișiere. Instrumentul standard nu oferă rezultate precise, dar comanda btrfs din pachetul btrfs-progs include o implementare a comenzii df care afișează spațiul disponibil cu mai multe detalii. Consultați [[FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F|FAQ]] pentru o explicație mai detaliată a contabilizării spațiului liber în btrfs.
DUP: O variantă a „RAID” care stochează două copii ale fiecărui element de date pe același dispozitiv. Aceasta este similară cu RAID1 și oferă protecție împotriva erorilor la nivel de bloc pe dispozitiv, dar nu oferă nicio garanție în cazul în care întregul dispozitiv se defectează. În mod implicit, btrfs utilizează profilul DUP pentru metadate în sistemele de fișiere cu un singur dispozitiv.
ENOSPC: Cod de eroare returnat de sistemul de operare către un program al utilizatorului atunci când sistemul de fișiere nu poate aloca suficient spațiu pentru a satisface solicitarea utilizatorului. În majoritatea sistemelor de fișiere, acesta indică faptul că nu există spațiu liber disponibil în sistemul de fișiere. Datorită cerințelor suplimentare de spațiu impuse de comportamentul COW al btrfs, btrfs poate returna uneori ENOSPC chiar și atunci când, aparent (conform comenzii df), există o cantitate mare de spațiu liber. Aceasta este, de fapt, o eroare în btrfs și (dacă este repetabilă), utilizarea opțiunii de montare enospc_debug poate genera un raport care va ajuta dezvoltatorii btrfs. Consultați [[FAQ#if_your_device_is_large_.28.3E16GiB.29|intrarea din FAQ]] privind spațiul liber.
extent: Secvență contiguă de octeți pe disc care stochează datele fișierului. Aceasta reprezintă o reprezentare compactă care ține evidența punctului de început și a lungimii intervalului de octeți, astfel încât logica care stă la baza alocării blocurilor (delayed allocation -- alocare întârziată) urmărește maximizarea lungimii înainte de scrierea extensiilor pe dispozitive.
extent buffer: O abstractizare a unui bloc de metadate b-tree care stochează chei și date de element. Structurile conexe subiacente sunt un bloc de dispozitiv fizic și o pagină de memorie CPU.
fallocate: Instrument de linie de comandă din pachetul util-linux și un apel de sistem care rezervă spațiu în sistemul de fișiere pentru un fișier, fără a scrie efectiv date ale fișierului în sistemul de fișiere. Prima scriere de date va transforma extinderile prealocate în extinderi obișnuite. Vezi fallocate (1) și paginile de manual fallocate(2) pentru mai multe detalii.
filefrag: Un instrument care afișează numărul de extinderi (extents) dintr-un fișier și, prin urmare, gradul de fragmentare al acestuia. De obicei, acesta face parte din pachetul e2fsprogs în majoritatea distribuțiilor Linux. Deși a fost dezvoltat inițial pentru sistemul de fișiere ext2, funcționează și pe Btrfs. Utilizează comanda ioctl FIEMAP.
free space cache: Cunoscut, de asemenea, sub denumirea de „space cache v1 -- cache de spațiu v1”. Un cache separat care ține evidența spațiului liber, întrucât Btrfs urmărește doar spațiul alocat. Spațiul liber este, prin definiție, orice interval liber dintre intervalele alocate. Identificarea intervalelor libere poate implica o activitate intensă de operații de In/Ieș, astfel încât cache-ul stochează o reprezentare condensată a acestora. Acesta este actualizat la fiecare confirmare a unei tranzacții.
Memoria cache de spațiu liber v1 a fost înlocuită de arborele de spațiu liber.
free space tree: Succesorul lui free space cache, cunoscut și ca „space cache v2” și acum implicit. Spațiul liber este urmărit într-un mod mai bun și folosind COW, spre deosebire de un mecanism personalizat din v1.
fsync: Pe sistemele de operare Unix și de tip Unix (din care Linux face parte), apelul de sistem „fsync(2) descriptorii de fișiere stocate în memoria tampon pe dispozitivul de blocuri subiacent. Când un fișier este modificat pe un sistem de operare modern, modificările nu sunt, în general, scrise imediat pe disc, ci sunt stocate în memoria tampon din motive de performanță; apelarea fsync(2) determină scrierea pe disc a oricăror modificări din memorie.
generation: Un contor intern care se actualizează la fiecare tranzacție. Atunci când se scrie un bloc de metadate (folosind „copy-on-write”), generația curentă este stocată în bloc, astfel încât blocurile prea recente (și, prin urmare, posibil inconsistente) să poată fi identificate.
key: Un tuple de dimensiune fixă utilizat pentru identificarea și sortarea elementelor dintr-un arbore-B B-tree. Cheia este împărțită în trei părți: objectid, type și offset. Câmpul type indică modul în care trebuie utilizate celelalte două câmpuri și ce se poate găsi în elementul respectiv.
item: O structură de mărime variabilă stocată în frunze B-tree. Elementele conțin diferite tipuri de date în funcție de tipul cheii.
log tree: Un b-tree care urmărește temporar actualizările de metadate în curs de desfășurare până când se efectuează o comitere completă a tranzacției. Este o optimizare de performanță a fsync. Jurnalul urmărit în arbore este reluat dacă sistemul de fișiere nu este demontat curat.
metadata: Date despre date. În btrfs, acestea includ toate structurile interne de date ale sistemului de fișiere, inclusiv structuri de directoare, nume de fișiere, permisiuni de fișiere, sume de control și locația extents a fiecărui fișier. Toate metadatele btrfs sunt stocate în B-trees.
mkfs.btrfs: Instrumentul (din btrfs-progs) pentru a crea un sistem de fișiere btrfs.
offline: Un sistem de fișiere care nu este montat este inactiv (offline). Unele instrumente (de exemplu btrfsck) vor funcționa numai pe sisteme de fișiere inactive. Comparați cu online.
online: Un sistem de fișiere care este montat este activ (online). Majoritatea instrumentelor btrfs vor funcționa numai pe sisteme de fișiere active. Comparați cu offline.
orphan: Un fișier care este încă în uz (deschis de un proces în desfășurare), dar toate intrările de director ale fișierului respectiv au fost eliminate.
RAID: O clasă de metode diverse pentru scrierea unor date redundante suplimentare pe mai multe dispozitive, astfel încât, în cazul în care un dispozitiv se defectează, datele pierdute să poată fi reconstituite pe baza celor rămase. A se vedea RAID0, RAID1, RAID5, RAID6, RAID10, DUP și single. Metodele RAID tradiționale funcționează pe mai multe dispozitive de dimensiuni egale, în timp ce implementarea btrfs' RAID funcționează în interiorul block groups -- grupurilor de blocuri.
RAID0: O formă de RAID care nu oferă garanții de recuperare în caz de eroare, dar realizează o singură copie a datelor pe mai multe dispozitive în scopuri de performanță. Dimensiunea benzii (stripe) este fixată la 64Ko pentru moment.
RAID1, RAID1C3, RAID1C4: O variantă de RAID care stochează două/trei/patru copii complete ale fiecărui element de date. Fiecare copie este stocată pe un dispozitiv diferit. btrfs necesită cel puțin două dispozitive pentru a utiliza RAID-1 sau, respectiv, trei/patru. Acesta este profilul implicit al grupului de blocuri pentru btrfs, care stochează metadatele pe mai multe dispozitive.
RAID5: O formă de RAID care împarte o singură copie a datelor pe mai multe dispozitive, inclusiv datele de paritate suplimentare ale unui dispozitiv. Poate fi utilizată pentru recuperarea datelor în cazul defectării unui singur dispozitiv.
RAID6: O formă de RAID care împarte o singură copie a datelor pe mai multe dispozitive, inclusiv date de paritate suplimentare echivalente cu două dispozitive. Poate fi utilizată pentru recuperarea datelor în cazul defectării a două dispozitive.
RAID10: O formă de RAID care stochează două copii complete ale fiecărei date și, de asemenea, împarte fiecare copie pe mai multe dispozitive pentru a îmbunătăți performanța.
reflink: Termenul este folosit de obicei pentru a desemna o copie superficială a segmentelor(extents) de fișier care împart aceleași segmente până la prima modificare. Fișierele cu legături refăcute „reflinked” (de exemplu, prin comanda cp) sunt fișiere diferite, dar care indică aceleași segmente; orice modificare va fi detectată și se va crea o nouă copie a datelor, menținând fișierele independente. În legătură cu acest concept se află clonarea unui interval de segmente, care se aplică unui interval dintr-un fișier.
relocation: Procesul de mutare a grupurilor de blocuri în cadrul sistemului de fișiere, menținând în același timp integritatea și coerența completă a sistemului de fișiere. Această funcționalitate stă la baza funcțiilor de eliminare balance și device.
scrub: Un instrument de verificare a sistemului de fișiere activ. Citește toate datele și metadatele din sistemul de fișiere, verifică sumele de control și, în cele din urmă, utilizează copii redundante din RAID sau DUP pentru a repara orice date/metadate corupte.
seed device: Un dispozitiv numai pentru citire poate fi folosit ca sursă inițială(sămânță) sau șablon pentru un sistem de fișiere (de exemplu, un CD-ROM care conține o imagine a sistemului de operare). Se pot adăuga dispozitive de citire/scriere pentru a stoca modificările (folosind copy on write); modificările aduse dispozitivelor inscriptibile sunt persistente chiar și după repornirea sistemului. Dispozitivul original rămâne neschimbat și poate fi îndepărtat în orice moment (după ce Btrfs a primit instrucțiuni să copieze toate blocurile lipsă). Se pot construi mai multe sisteme de fișiere de citire/scriere pornind de la aceeași sămânță.
single: Un profil de grup de blocuri care stochează o singură copie a fiecărei informații.
snapshot: Un sub-volum subvolume care este o copie copy on write a unui alt subvolum. Cele două subvolume partajează toate datele comune (nemodificate), ceea ce înseamnă că instantaneele pot fi utilizate pentru a păstra istoricul unui sistem de fișiere cu un cost foarte redus. După realizarea instantaneei, subvolumul original și instantaneea au statut egal: originalul nu „deține” instantaneea, iar oricare dintre ele poate fi șters fără a-l afecta pe celălalt.
subvolume: O structură ierarhică de fișiere și directoare din cadrul unui sistem de fișiere Btrfs, care poate fi montată ca și cum ar fi un sistem de fișiere independent. Un sub-volum se creează prin stabilirea unei referințe la rădăcina unui alt sub-volum. Fiecare sistem de fișiere btrfs are cel puțin un sub-volum, top-level subvolume -- sub-volumul de nivel superior, care conține tot restul sistemului de fișiere. Sub-volumele suplimentare pot fi create și șterse cu instrumentul btrfs<. Toate sub-volumele împart același spațiu liber din sistemul de fișiere. Vezi și default subvolume -- sub-volumul implicit.
super block: Un bloc special de metadate care constituie punctul principal de acces la structurile sistemului de fișiere. Dimensiunea acestuia este fixă, iar pe dispozitive există locații fixe utilizate pentru detectarea și deschiderea sistemului de fișiere. Actualizarea superblocului definește o tranzacție. Superblocul conține identificatorul sistemului de fișiere (UUID), tipul de sumă de control, indicatori de blocuri către arborii fundamentali, caracteristici și parametri de creare.
system array: Un termen tehnic care se referă la metadatele super block ce descriu modul de asamblare a unui sistem de fișiere din mai multe dispozitive, stocând informații despre blocuri și dispozitive care trebuie scanate/înregistrate în momentul montării. Scanarea se efectuează prin comanda btrfs device scan; alternativ, toate dispozitivele necesare pot fi specificate printr-o opțiune de montare device=/ruta.
top-level subvolume: subvolume în partea de sus a sistemului de fișiere. Acesta este singurul subvolum prezent într-un sistem de fișiere btrfs nou creat și are ID-ul 5 intern, altfel ar putea fi referit ca 0 (de exemplu, în subcomanda set-default a btrfs).
transaction: Un set coerent de modificări. Pentru a evita generarea unui volum foarte mare de activitate pe disc, btrfs stochează modificările în memoria RAM timp de până la 30 de secunde (uneori mai des dacă sistemul de fișiere rămâne fără spațiu sau efectuează numeroase operații fsync), apoi scrie (confirmă) aceste modificări pe disc dintr-o singură dată (folosind comportamentul copy-on-write). Această perioadă de stocare în cache se numește tranzacție. Doar o singură tranzacție este activă pe sistemul de fișiere în orice moment.
transid: Un termen alternativ pentru generation.
writeback: Writeback în contextul nucleului Linux poate fi definit ca procesul de scriere a memoriei „murdare” din cache-ul paginii pe disc, atunci când sunt îndeplinite anumite condiții (expirarea timpului, numărul de pagini murdare peste un anumit raport).

MODEL DE STOCARE, CONSIDERENTE HARDWARE¶

Modelul de stocare¶

Un model de stocare este un model care surprinde aspectele fizice cheie ale structurii datelor într-un spațiu de stocare a datelor. Un sistem de fișiere este structura logică care organizează datele pe dispozitivul de stocare.

Sistemul de fișiere ține cont de anumite caracteristici sau limitări ale dispozitivului de stocare și le utilizează sau aplică măsuri pentru a asigura fiabilitatea. BTRFS, în special, se bazează pe un mod de scriere COW (copy on write), adică nu actualizează datele pe loc (fără utilizarea unui tampon sau fișier temporar), ci scrie o nouă copie într-o altă locație și apoi comută indicatorii în mod atomic.

Într-o lume ideală, dispozitivul face exact ceea ce promite. Sistemul de fișiere pornește de la premisa că acest lucru s-ar putea să nu fie adevărat, așa că se aplică mecanisme suplimentare fie pentru a detecta defecțiuni hardware, fie pentru a obține date valide prin alte mijloace. Dispozitivele pot (și chiar o fac) să-și aplice propriile mecanisme de detectare și reparare, dar noi nu vom presupune existența niciunui astfel de mecanism.

Se iau în considerare următoarele ipoteze privind dispozitivele de stocare (ordonate după importanță, numerele sunt pentru referințe ulterioare):

1.: atomicitatea citirilor și scrierilor de blocuri/sectoare (cea mai mică unitate de date pe care dispozitivul o prezintă straturilor superioare)
2.: există o comandă de golire care instruiește dispozitivul să ordoneze în mod forțat scrierile înainte și după comandă; alternativ, există o comandă de barieră care facilitează ordonarea, dar care poate să nu golească datele
3.: datele trimise pentru a fi scrise într-o anumită poziție pe un dispozitiv vor fi scrise fără modificări suplimentare ale datelor și ale poziției
4.: scrierile pot fi reordonate de dispozitiv, cu excepția cazului în care sunt serializate în mod explicit prin comanda flush
5.: citirile și scrierile pot fi reordonate și intercalate în mod liber

Modelul de consistență al BTRFS se bazează pe aceste ipoteze. Actualizările logice ale datelor sunt grupate într-o generație, scrise pe dispozitiv, serializate prin comanda «flush», iar apoi se scrie super-blocul, ceea ce încheie generația. Niciuna dintre legăturile logice dintre metadate care alcătuiesc o viziune consistentă asupra datelor nu poate depăși limita generației.

Când lucrurile merg prost¶

Atomicitate nulă sau parțială a citirilor/scrierilor în bloc (1)

Problemă: conținutul unui bloc parțial este scris (scriere întreruptă), de exemplu din cauza unei întreruperi de curent sau a unei alte defecțiuni electronice în timpul citirii/scrierii.
Detectare: nepotrivire sumă de control la citire
Reparare: utilizați o altă copie sau reconstruiți din mai multe blocuri utilizând o schemă de codificare

Comanda flush nu efectuează golirea (2)

Aceasta este probabil cea mai gravă problemă și este imposibil de remediat la nivelul sistemului de fișiere fără impunerea unor limitări și restricții de proiectare. În cel mai rău caz, s-ar putea întâmpla ca operațiile de scriere dintr-o generație să se suprapună peste cele dintr-o altă generație, în timp ce sistemul de fișiere continuă să considere generațiile ca fiind izolate. O blocare în orice moment ar lăsa datele de pe dispozitiv într-o stare inconsistentă, fără niciun indiciu cu privire la ce anume a fost scris, ce lipsește, ceea ce ar duce la informații învechite privind legăturile metadatelor.

Dispozitivele respectă de obicei comanda de golire «flush», dar, din motive de performanță, pot recurge la stocarea în cache internă, caz în care datele golite nu sunt încă stocate permanent. O pană de curent ar putea duce la un scenariu similar cu cel de mai sus, deși este mai puțin probabil ca scrierile ulterioare să fie scrise înaintea celor din cache. Acest lucru depășește ceea ce poate lua în considerare un sistem de fișiere. Dispozitivele sau controlorii sunt de obicei echipate cu baterii sau condensatoare pentru a scrie conținutul cache-ului chiar și după întreruperea alimentării cu energie electrică. (Battery backed write cache -- cache de scriere susținut de baterie)

Datele sunt modificate în mod silențios la scriere (3)

Astfel de lucruri nu ar trebui să se întâmple frecvent, dar pot apărea în mod neașteptat din cauza funcționării interne complexe a dispozitivelor sau a efectelor fizice ale suportului de stocare în sine.

Problemă: în timp ce datele sunt scrise atomic, conținutul se modifică
Detectare: nepotrivire sumă de control la citire
Reparare: utilizați o altă copie sau reconstruiți din mai multe blocuri utilizând o schemă de codificare

Datele sunt scrise în mod silențios într-o altă poziție (3)

Aceasta ar fi o altă problemă gravă, deoarece sistemul de fișiere nu are informații când se întâmplă acest lucru. Din acest motiv, măsurile trebuie luate din timp. Această problemă este denumită în mod obișnuit ghost write (scriere fantomă).

Blocurile de metadate conțin suma de control încorporată, astfel încât o operație de scriere atomică corectă nu ar altera suma de control. Este foarte probabil ca, după citirea unui astfel de bloc, datele din interiorul acestuia să nu mai fie în concordanță cu restul. Pentru a exclude această posibilitate, în blocul de metadate este încorporat numărul blocului. Acesta este numărul blocului logic, deoarece aceasta este informația pe care structura logică o așteaptă și o verifică.

Următoarele informații se bazează pe informații disponibile public, comentarii/opinii ale utilizatorilor, discuții în comunitate sau analize ale rapoartelor de erori. Acestea nu sunt complete și, în caz de dubiu, se recomandă efectuarea de cercetări suplimentare.

Memoria principală¶

Structurile de date și blocurile de date brute sunt stocate temporar în memoria calculatorului înainte de a fi scrise pe dispozitiv. Este esențial ca memoria să fie fiabilă, deoarece chiar și simple inversări de biți pot avea consecințe grave și pot duce la deteriorarea structurilor, nu doar în sistemul de fișiere, ci în întregul sistem de operare.

Pe baza experienței comunității, inversările de biți din memorie sunt mai frecvente decât s-ar crede. Când se întâmplă acest lucru, se manifestă prin erori semnalate de programul de verificare a arborelui sau prin neconcordanțe ale sumelor de control după citirea blocurilor. Există câteva cazuri foarte evidente de inversări de biți, de exemplu într-o secvență ordonată de chei din blocurile de metadate. Putem deduce cu ușurință din celelalte date ce valori sunt afectate și cum. Totuși, remedierea acestui lucru nu este simplă și ar necesita o referință încrucișată a datelor din întregul sistem de fișiere pentru a vedea amploarea problemei.

Dacă este disponibilă, memoria ECC ar trebui să reducă riscul de inversare a biților, dar acest tip de memorie nu este disponibil în toate cazurile. Ar trebui efectuat un test de memorie în cazul în care există un model vizibil de inversare de biți, deși este posibil ca acesta să nu detecteze un modul de memorie defect, deoarece încărcarea reală a sistemului ar putea fi factorul care determină apariția problemelor. În ultimii ani au fost demonstrate atacuri asupra modului de funcționare a modulelor de memorie (rowhammer) care au reușit să inverseze biți specifici. Deși acestea au fost țintite, acest lucru arată că o serie de operații de citire sau scriere pot afecta părți ale memoriei care nu au legătură între ele.

Profilurile grupurilor de blocuri cu redundanță (cum ar fi RAID1) nu protejează împotriva erorilor de memorie, deoarece blocurile sunt mai întâi stocate în memorie înainte de a fi scrise pe dispozitive din aceeași sursă.

Un sistem de fișiere montat în mod „doar-citire” nu va afecta dispozitivul de blocuri subiacent în aproape 100% din cazuri (cu excepții extrem de puțin probabile). Excepția o constituie jurnalul arborescent care trebuie rulat în timpul montării (și înainte ca montarea în mod „doar-citire” să aibă loc); pentru aceasta este necesară memoria de lucru, care poate fi afectată de inversări de biți. Există un caz teoretic în care o inversare de biți schimbă starea sistemului de fișiere din „doar-citire” în „citire-scriere”.

Lecturi suplimentare:

https://en.wikipedia.org/wiki/Row_hammer
overclocking-ul memoriei, XMP, riscuri potențiale

Ce trebuie făcut:

rulați memtest, rețineți că uneori erorile de memorie apar numai atunci când sistemul este supus unei sarcini mari, pe care memtest-ul implicit nu o poate declanșa
erorile de memorie pot apărea ca sistem de fișiere care devine numai pentru citire din cauza verificării „pre-scriere”, care verifică metadatele înainte ca acestea să fie scrise, dar eșuează la unele verificări de consistență de bază
sistemele nou construite ar trebui testate înainte de a fi utilizate în producție, în mod ideal pornind o sarcină IO/CPU care va fi rulată ulterior pe un astfel de sistem; mai precis sistemele care vor utiliza overclocking sau caracteristici speciale de performanță

Acces direct la memorie (DMA)¶

O altă categorie de erori este legată de DMA (direct memory access -- acces direct la memorie) efectuat de controlorii de dispozitive. Deși acest lucru ar putea fi considerat o eroare de software, transferurile de date care au loc fără intervenția procesorului pot corupe accidental alte pagini. Dispozitivele de stocare utilizează DMA din motive de performanță; structurile sistemului de fișiere și paginile de date sunt transmise în ambele sensuri, ceea ce face posibile apariția erorilor în cazul în care durata de viață a paginilor nu este monitorizată corespunzător.

Există multe particularități (soluții specifice dispozitivelor) în controlorii nucleului Linux (nu numai în ceea ce privește DMA) care sunt adăugate atunci când sunt descoperite. Particularitățile pot evita anumite erori sau pot dezactiva unele funcții pentru a evita probleme mai grave.

Ce trebuie făcut:

utilizați un nucleu actualizat (versiuni recente sau versiuni cu suport pe termen lung)
deoarece acest lucru poate fi cauzat de controlori defectuoși, mențineți sistemele actualizate

Discuri rotative (HDD)¶

Discurile dure rotative (HDD) se defectează de obicei la nivelul sectoarelor individuale sau al grupurilor mici de sectoare. Erorile de citire sunt detectate la nivelurile inferioare sistemului de fișiere și sunt afișate utilizatorului sub forma EIO - Eroare de intrare/ieșire. Citirea repetată a blocurilor poate duce în cele din urmă la recuperarea datelor, dar această operație este mai bine realizată de instrumente specializate, iar sistemul de fișiere preia rezultatul de la nivelurile inferioare. Rescrierea sectoarelor poate declanșa o recartografiere internă, dar acest lucru duce inevitabil la pierderea datelor.

Firmware-ul discului este, din punct de vedere tehnic, un program, dar din perspectiva sistemului de fișiere face parte din componentele hardware. Se procesează cererile de In/Ieș și se efectuează operații de stocare în cache sau diverse alte optimizări, ceea ce poate duce la apariția unor erori în condiții de încărcare intensă, în situații fizice neprevăzute sau în cazuri de utilizare neacceptate.

Discurile sunt conectate prin cabluri cu două capete, ambele putând cauza probleme dacă nu sunt conectate corespunzător. Transferurile de date sunt protejate prin sume de control, iar straturile inferioare fac tot posibilul să transfere datele corect sau deloc. Erorile cauzate de cablurile conectate necorespunzător se pot manifesta sub forma unui număr mare de cereri de citire sau scriere eșuate sau sub forma unor scurte rafale de erori, în funcție de condițiile fizice.

Ce trebuie făcut:

•: rulați smartctl pentru a identifica potențialele probleme

Unități de stocare în stare solidă („Solid state drives”: SSD)¶

Mecanismul de stocare a informațiilor diferă de cel al HDD-urilor, iar acest lucru influențează și modul de defectare. Datele sunt stocate în celule grupate în blocuri mari, cu un număr limitat de reinițializări și alte restricții de scriere. Firmware-ul încearcă să evite reinițializările inutile și efectuează optimizări pentru a maximiza durata de viață a suportului de stocare. Tehnicile cunoscute sunt de-duplicarea (blocurile cu aceeași amprentă/hash sunt asociate aceluiași bloc fizic), compresia sau realocarea internă și colectarea deșeurilor din celulele de memorie utilizate. Datorită procesării suplimentare, există măsuri de verificare a datelor, de exemplu prin coduri ECC.

Observațiile privind SSD-urile defecte arată că întregul sistem electronic se defectează brusc sau afectează o cantitate mare de date (de exemplu, stocate pe un singur cip). Recuperarea acestor date poate necesita echipamente specializate, iar citirea repetată a datelor nu ajută, așa cum se întâmplă în cazul HDD-urilor.

Există mai multe tipuri de celule de memorie, cu caracteristici și prețuri diferite. Durata de viață este influențată direct de tipul și frecvența datelor scrise. Scrierea unui volum „prea mare” de date distincte (de exemplu, date criptate) poate face ca de-duplicarea internă să devină ineficientă și poate duce la numeroase rescrieri și la o uzură sporită a celulelor de memorie.

Există mai multe tehnologii și producători, astfel încât este dificil să le descriem, dar unele dintre ele prezintă un comportament similar:

SSD-urile scumpe utilizează celule de memorie mai durabile și sunt optimizate pentru fiabilitate și sarcină mare
SSD-urile ieftine sunt proiectate pentru o încărcare mai mică („utilizatori casnici”) și sunt optimizate din punct de vedere al costurilor, putând utiliza optimizările și/sau raportarea extinsă a erorilor parțial sau deloc

Nu este posibil să se determine în mod fiabil durata de viață preconizată a unui SSD din cauza lipsei de informații despre modul în care funcționează sau din cauza lipsei de statistici fiabile furnizate de dispozitiv.

Scrierile de metadate tind să fie cea mai mare componentă a scrierilor pe durata de viață a unui SSD, astfel încât reducerea acestora are o anumită valoare. În funcție de clasa dispozitivului (high end/low end), caracteristici precum profilurile grupurilor de blocuri DUP pot afecta fiabilitatea în ambele sensuri:

high end sunt de obicei mai fiabile, iar utilizarea single pentru date și metadate ar putea fi potrivită pentru a reduce uzura dispozitivului
low end ar putea să nu aibă capacitatea de a identifica erorile, astfel încât o redundanță suplimentară la nivel de sistem de fișiere (sumele de control, DUP) ar putea fi de ajutor

Doar utilizatorii care consumă între 50 și 100% din capacitatea reală de scriere pe durata de viață a SSD-ului trebuie să fie preocupați de amplificarea scrierilor generată de metadatele DUP ale sistemului de fișiere btrfs. Majoritatea utilizatorilor se vor situa cu mult sub 50% din această capacitate, sau vor scrie pe unitate până la epuizarea acesteia și vor descoperi cât de multe operații de scriere reprezintă 100% din capacitatea reală. Firmware-ul SSD adaugă adesea proprii multiplicatori de scriere, care pot fi arbitrari și imprevizibili și depind de comportamentul aplicației, iar aceștia vor avea, de obicei, un efect mult mai mare asupra duratei de viață a SSD-ului decât metadatele DUP. Este mai mult sau mai puțin imposibil să se prevadă când un SSD va epuiza capacitatea de scriere pe durata de viață cu o marjă de eroare de maximum două ori, așa că este greu să se justifice reducerea uzurii ca un beneficiu.

Lecturi suplimentare:

Ce trebuie făcut:

rulați smartctl sau autotestele pentru a identifica potențialele probleme
mențineți firmware-ul actualizat

Memorie expresă nevolatilă NVM (NVMe)¶

NVMe este un tip de memorie persistentă conectată de obicei printr-un magistrală de sistem (PCIe) sau o interfață similară, iar vitezele sale sunt cu un ordin de mărime mai mari decât cele ale SSD-urilor. De asemenea, este un tip de stocare fără piese rotative și, de obicei, nu se conectează prin cablu. Nu este nici un dispozitiv de tip SCSI, ci mai degrabă o specificație completă pentru interfața dispozitivelor logice.

Într-un fel, erorile pot fi comparate cu o combinație între clasa SSD și memoria obișnuită. Erorile pot apărea sub formă de inversări aleatoare de biți sau erori de In/Ieș. Există instrumente pentru accesarea jurnalului intern (nvme log și nvme-cli) pentru o analiză mai detaliată.

Există etape separate de detectare și corectare a erorilor, efectuate, de exemplu, la nivelul magistralei, iar în majoritatea cazurilor acestea nu ajung niciodată la nivelul sistemului de fișiere. Dacă se întâmplă acest lucru, ar putea însemna că există o eroare sistematică, cum ar fi supraîncălzirea sau o conexiune fizică defectuoasă a dispozitivului. Vă recomandăm să rulați auto-testele (folosind comanda smartctl).

Firmware pentru unitate¶

Din punct de vedere tehnic, firmware-ul este tot un tip de software, dar integrat în hardware. La fel ca orice software, și firmware-ul poate conține erori. Dispozitivele de stocare pot actualiza firmware-ul și remedia erorile cunoscute. În unele cazuri, este posibil să se evite anumite erori prin utilizarea unor soluții de compromis (soluții specifice dispozitivului) în nucleul Linux.

Un firmware defectuos poate provoca o gamă largă de corupții, de la cele mici și localizate până la cele mari, care afectează o mulțime de date. Capacitățile de autoreparare pot fi insuficiente.

Ce trebuie făcut:

verificați dacă există actualizări de firmware în cazul în care există probleme cunoscute; rețineți că actualizarea firmware-ului poate fi riscantă în sine
utilizați un nucleu actualizat (versiuni recente sau versiuni cu suport pe termen lung)

Carduri flash SD¶

Există numeroase dispozitive cu consum redus de energie, care utilizează, prin urmare, suporturi de stocare cu consum redus de energie, de obicei memorie flash stocată pe un cip încorporat într-o carcasă detașabilă sub formă de card. Un card introdus incorect poate fi deteriorat de vârfuri de tensiune atunci când dispozitivul este pornit sau oprit. La rândul lor, cipurile care stochează datele pot fi deteriorate permanent. Toate tipurile de memorie flash au un număr limitat de rescrieri, astfel încât datele sunt traduse intern de FTL (flash translation layer). Acest lucru este implementat în firmware (din punct de vedere tehnic, un software) și este predispus la erori care se manifestă ca erori hardware.

Adăugarea de redundanță, cum ar fi utilizarea profilurilor DUP atât pentru date, cât și pentru metadate, poate fi utilă în unele cazuri, dar o copie de rezervă completă ar putea fi cea mai bună opțiune odată ce apar probleme, iar înlocuirea cardului ar putea fi, de asemenea, necesară.

Hardware-ul ca sursă principală a corupției sistemului de fișiere¶

Dacă utilizați hardware nesigur și nu știți acest lucru, nu dați vina pe sistemul de fișiere când vă avertizează.

CONSULTAȚI ȘI¶

acl(5), btrfs(8), chattr(1), fstrim(8), ioctl(2), btrfs-ioctl(2), mkfs.btrfs(8), mount(8), swapon(8)

TRADUCERE¶

Traducerea în limba română a acestui manual a fost făcută de Remus-Gabriel Chelu <remusgabriel.chelu@disroot.org>

Această traducere este documentație gratuită; citiți Licența publică generală GNU Versiunea 3 sau o versiune ulterioară cu privire la condiții privind drepturile de autor. NU se asumă NICIO RESPONSABILITATE.

Dacă găsiți erori în traducerea acestui manual, vă rugăm să trimiteți un e-mail la translation-team-ro@lists.sourceforge.net.

13 februarie 2026

6.19

Source file:	btrfs.5.ro.gz (from man-pages-ro 4.31.0-1.1)
Source last updated:	2026-06-29T09:41:50Z
Converted to HTML:	2026-07-03T00:55:45Z