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.: operaț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 zonat
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) <https://man7.org/linux/man-pages/man8/mount.8.html> și consultați, de asemenea, secțiunea cu detalii specifice BTRFS de mai jos <btrfs-man5//# mount-options-generic>. Opțiunile sunt sortate alfabetic (fără prefixul no).

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 manualului acl(5) <https://man7.org/linux/man-pages/man5/acl.5.html> 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 au, de asemenea, atributul de fișier NOCOW (consultați chattr(1) <https://man7.org/linux/man-pages/man1/chattr.1.html>).

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ă suma de control a datelor pentru fișierele nou create. Datasum implică datacow, adică modul normal de funcționare. Toate fișierele create sub nodatasum moștenesc proprietatea „no checksums”, însă nu există un atribut de fișier corespondent (a se vedea chattr(1) <https://man7.org/linux/man-pages/man1/chattr.1.html>).

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 numa-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 procedura de reconstruire a arborelui UUID. În mod normal, acest lucru nu ar trebui să fie necesar. Alternativ, arborele poate fi șters din spațiul utilizatorului prin comanda btrfs rescue clear-uuid-tree <#man-rescue-clear-uuid-tree>, iar apoi va fi 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 sub-volumului a fost restricționată. Crearea sub-volumului a fost restricționată, dar această opțiune de montare este încă necesară. Aceasta reprezintă o problemă de utilizare. Începând cu versiunea 4.18, apelul de sistem rmdir(2) <https://man7.org/linux/man-pages/man2/rmdir.2.html> 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 din 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, orice date vechi create prin utilizarea anterioară a opțiunii inode_cache pot fi eliminate prin btrfs rescue clear-ino-cache <#man-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) <https://man7.org/linux/man-pages/man8/mount.8.html> 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 condiții de încărcare intensă de citire, specificarea opțiunii noatime îmbunătățește semnificativ performanța, deoarece nu este necesară scrierea de noi informații 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 scenariu 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. A se vedea și <https://lwn.net/Articles/499293/> - Atime and btrfs: a bad combination? (LWN, 2012-05-31).
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 verificare a sumelor 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 extragerea și afișarea super-blocului; puteți corela valoarea lui incompat_flags cu funcționalitățile 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 (a se vedea și mkfs.btrfs(8) <> secțiunea CARACTERISTICI ALE SISTEMULUI DE FIȘIERE <#man-mkfs-filesystem-features>):

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 superbloc, în timp ce toate blocurile de metadate au încă UUID-ul stabilit la momentul mkfs, consultați 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ă apelul de sistem rmdir(2) %<https://man7.org/linux/man-pages/man2/rmdir.2.html> poate șterge un subvolum gol la fel ca un director obișnuit. Rețineți că această caracteristică depinde numai 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ă într-un fișier. Este acceptat începând cu versiunea 5.0 a nucleului. Folosiți swapon(8) <https://man7.org/linux/man-pages/man8/swapon.8.html> pentru a-l activa, până atunci (respectiv din nou după dezactivarea acestuia cu swapoff (8) <https://man7.org/linux/man-pages/man8/swapoff.8.html>) 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 <#man-inspect-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 supports transparent file compression. There are three algorithms available: ZLIB, LZO and ZSTD (since v4.14), with various levels. The compression happens on the level of file extents and the algorithm is selected by file property, mount option or by a defrag command. You can have a single btrfs mount point that has some files that are uncompressed, some that are compressed with LZO, some with ZLIB, for instance (though you may not want it that way, it is supported).

Once the compression is set, all newly written data will be compressed, i.e. existing data are untouched. Data are split into smaller chunks (128KiB) before compression to make random rewrites possible without a high performance hit. Due to the increased number of extents the metadata consumption is higher. The chunks are compressed in parallel.

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

The differences depend on the actual data set and cannot be expressed by a single number or recommendation. Higher levels consume more CPU time and may not bring a significant improvement, lower levels are close to real time.

CUM SE ACTIVEAZĂ COMPRIMAREA¶

Typically the compression can be enabled on the whole filesystem, specified for the mount point. Note that the compression mount options are shared among all mounts of the same filesystem, either bind mounts or subvolume mounts. Please refer to btrfs(5) <> section MOUNT OPTIONS.

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

This will enable the zstd algorithm on the default level (which is 3). The level can be specified manually too like zstd:3. Higher levels compress better at the cost of time. This in turn may cause increased write latency, low levels are suitable for real-time compression and on reasonably fast CPU don't cause noticeable performance drops.

$ btrfs filesystem defrag -czstd fișier

The command above will start defragmentation of the whole file and apply the compression, regardless of the mount option. The compression level can be also specified with the --level or -L argument as of version 6.14. The compression algorithm is not persistent and applies only to the defragmentation command, for any other writes other compression settings apply.

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

The first command is using legacy interface of file attributes inherited from ext2 filesystem and is not flexible, so by default the zlib compression is set. The other command sets a property on the file with the given algorithm. (Note: setting level that way is not yet implemented.)

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.

There are 9 levels of ZLIB supported (1 to 9), mapping 1:1 from the mount option to the algorithm defined level. The default is level 3, which provides the reasonably good compression ratio and is still reasonably fast. The difference in compression gain of levels 7, 8 and 9 is comparable but the higher levels take longer.

The ZSTD support includes levels -15..15, a subset of full range of what ZSTD provides. Levels -15..-1 are real-time with worse compression ratio, levels 1..3 are near real-time with good compression, 4..8 are slower with improved compression and 9..15 try even harder though the resulting size may not be significantly improved. Higher levels also require more memory and as they need more CPU the system performance is affected.

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.

The reason for this is that a successful fallocate call must guarantee that future writes to the allocated range will not fail because of lack of space. This is difficult to guarantee in a COW filesystem. To reduce the chances of it happening, btrfs preallocates space and disables compression for the file.

As a workaround, one can trigger a compressed rewrite for such a file using the btrfs defrag command. Be aware that if the file is touched again by the fallocate system call, it will be excepted again from compression for all the new data written to it.

DATE INCOMPREHENSIBILE¶

Files with already compressed data or with data that won't compress well with the CPU and memory constraints of the kernel implementations are using a simple decision logic. If the first portion of data being compressed is not smaller than the original, the compression of the whole file is disabled. Unless the filesystem is mounted with compress-force in which case btrfs will try compressing every block, falling back to storing the uncompressed version for each block that ends up larger after compression. This is not optimal and subject to optimizations and further development.

If a file is identified as incompressible, a flag is set (NOCOMPRESS) and it's sticky. On that file compression won't be performed unless forced. The flag can be also set by chattr +m (since e2fsprogs 1.46.2) or by properties with value no or none. Empty value will reset it to the default that's currently applicable on the mounted filesystem.

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
pre-compression heuristics - a quick statistical evaluation on the data is performed and based on the result either compression is performed or skipped, the NOCOMPRESS bit is not set just by the heuristic, only if the compression algorithm does not make an improvement

$ 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¶

The heuristics aim to do a few quick statistical tests on the compressed data in order to avoid probably costly compression that would turn out to be inefficient. Compression algorithms could have internal detection of incompressible data too but this leads to more overhead as the compression is done in another thread and has to write the data anyway. The heuristic is read-only and can utilize cached memory.

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 de î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 î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)

Shows the chunk size. Can be changed for data and metadata (independently) and cannot be set for system block group type. Cannot be set for zoned devices as it depends on the fixed device zone size. Upper bound is 10% of the filesystem size, the value must be multiple of 256MiB and greater than 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.

When dropping large subvolumes with qgroup enabled, there would be a huge load for qgroup accounting. If we have a subtree whose level is larger than or equal to this value, we will not trigger qgroup account at all, but mark qgroup inconsistent to avoid the huge workload.

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 (since 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 (symlink) poate să nu fie o rută validă, adică componentele numelui rutei pot depăși limitele (NAME_MAX), nu există validare de conținut la crearea symlink(3) <https://man7.org/linux/man-pages/man3/symlink.3.html>.
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 1Mio de pe fiecare dispozitiv este neutilizat, cu excepția super-blocului primar care se află la poziția 64Kio și se întinde pe 4Kio. Restul poate fi utilizat liber de încărcătoarele de pornire sau pentru alte informații de sistem. Rețineți că pornirea de pe un sistem de fișiere de pe dispozitivul împărțit în zone (zoned) <> 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) <https://man7.org/linux/man-pages/man1/chattr.1.html> sau lsattr(1) <https://man7. org/linux/man-pages/man1/lsattr.1.html> utilități (ioctl-urile sunt FS_IOC_GETFLAGS și FS_IOC_SETFLAGS), datorită numelor ioctl-urilor atributele sunt numite și fanioane
xflags: to distinguish from the previous, it's extended flags, with tunable bits similar to the attributes but extensible and new bits will be added in the future (the ioctls are FS_IOC_FSGETXATTR and FS_IOC_FSSETXATTR but they are not related to extended attributes that are also called xattrs), there's no standard tool to change the bits, there's support in xfs_io(8) <https://man7.org/linux/man-pages/man8/xfs_io.8.html> as command xfs_io -c chattr

Attributes have constraints associated and not all combinations can be set, the order of setting them also matters. Most attributes apply to files and directories but the semantics may differ. For directories the attribute may only mean to set this attribute to all new files (inheritable in the list below). Some attributes need root privileges to be set.

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) <https://man7.org/linux/man-pages/man8/dump.8.html>, pe BTRFS atributul poate fi activat/dezactivat dar nu se face nicio altă manipulare specială
D: (director) synchronous directory updates, pentru mai multe detalii căutați open(2) <https://man7.org/linux/man-pages/man2/open.2.html> 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) no compression, dezactivează definitiv comprimarea pe fișierul dat. Orice opțiuni de montare a comprimării nu vor afecta acest fișier. (chattr(1) <https://man7.org/linux/man-pages/man1/chattr.1.html> 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) <https://man7.org/linux/man-pages/man2/open.2.html> 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 de manual chattr(1) <https://man7.org/linux/man-pages/man1/chattr.1.html>.

XFLAGS¶

Există o suprapunere de litere atribuite biților cu atribute, această listă se referă la ceea ce oferă xfs_io(8) <https://man7:.org/linux/man-pages/man8/xfs_io.8:.html>:

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)¶

Since version 5.12 btrfs supports so called zoned mode. This is a special on-disk format and allocation/write strategy that's friendly to zoned devices. In short, a device is partitioned into fixed-size zones and each zone can be updated by append-only manner, or reset. As btrfs has no fixed data structures, except the super blocks, the zoned mode only requires block placement that follows the device constraints. You can learn about the whole architecture at <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¶

As said above, super block is handled in a special way. In order to be crash safe, at least one zone in a known location must contain a valid superblock. This is implemented as a ring buffer in two consecutive zones, starting from known offsets 0B, 512GiB and 4TiB.

The values are different than on non-zoned devices. Each new super block is appended to the end of the zone, once it's filled, the zone is reset and writes continue to the next one. Looking up the latest super block needs to read offsets of both zones and determine the last written version.

The amount of space reserved for super block depends on the zone size. The secondary and tertiary copies are at distant offsets as the capacity of the devices is expected to be large, tens of terabytes. Maximum zone size supported is 8GiB, which would mean that e.g. offset 0-16GiB would be reserved just for the super block on a hypothetical device of that zone size. This is wasteful but required to guarantee crash safety.

Recuperarea zonei, colectarea gunoiului¶

As the zones are append-only, overwriting data or COW changes in metadata make parts of the zones used but not connected to the filesystem structures. This makes the space unusable and grows over time. Once the ratio hits a (configurable) threshold a background reclaim process is started and relocates the remaining blocks in use to a new zone. The old one is reset and can be used again.

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¶

The WD Ultrastar series 600 advertises HM-SMR, i.e. the host-managed zoned mode. There are two more: DA (device managed, no zoned information exported to the system), HA (host aware, can be used as regular disk but zoned writes improve performance). There are not many devices available at the moment, the information about exact zoned mode is hard to find, check data sheets or community sources gathering information from real devices.

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

•: Ultrastar® DC ZN540 NVMe ZNS SSD (product brief <https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/collateral/product-brief/product-brief-ultrastar-dc-zn540.pdf>)

Emulat: null_blk¶

The driver null_blk provides memory backed device and is suitable for testing. There are some quirks setting up the devices. The module must be loaded with nr_devices=0 or the numbering of device nodes will be offset. The configfs must be mounted at /sys/kernel/config and the administration of the null_blk devices is done in /sys/kernel/config/nullb. The device nodes are named like /dev/nullb0 and are numbered sequentially. NOTE: the device name may be different than the named directory in 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 cuprinde 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

Emulated: TCMU runner¶

TCMU is a framework to emulate SCSI devices in userspace, providing various backends for the storage, with zoned support as well. A file-backed zoned device can provide more options for larger storage and zone size. Please follow the instructions at <https://zonedstorage.io/projects/tcmu-runner/> .

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)
superblock needs to be handled in a special way, there are still 3 copies but at different offsets (0, 512GiB, 4TiB) and the 2 consecutive zones are a ring buffer of the superblocks, finding the latest one needs reading it from the write pointer or do a full scan of the zones
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 lansat în versiunea 5.12 și 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 este o bibliotecă și un set de instrumente pentru manipularea directă a dispozitivelor cu suport ZBC/ZAC
<https://zonedstorage.io/projects/libzbd/> -- libzbd utilizează interfața dispozitivului de blocuri împărțit în zone furnizată de nucleu pe baza apelurilor de sistem ioctl()

<https://hddscan.com/blog/2020/hdd-wd-smr.html> -- câteva detalii despre tipurile exacte de dispozitive
<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)

The device is created when btrfs is initialized, either as a module or a built-in functionality and makes sense only in connection with that. Running e.g. mkfs without the module loaded will not register the device and will probably warn about that.

Î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

The control device is not strictly required but the device scanning will not work and a workaround would need to be used to mount a multi-device filesystem. The mount option device can trigger the device scanning during mount, see also btrfs device scan.

SISTEM DE FIȘIERE CU PROFILURI MULTIPLE¶

It is possible that a btrfs filesystem contains multiple block group profiles of the same type. This could happen when a profile conversion using balance filters is interrupted (see btrfs-balance(8) <>). Some btrfs commands perform a test to detect this kind of condition and print a warning like this:

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.

In the example above, the filesystem started as a single device and single block group profile. Then another device was added, followed by balance with convert=raid1 but for some reason hasn't finished. Restarting the balance with convert=raid1 will continue and end up with filesystem with all block group profiles RAID1.

Notă:

If you're familiar with balance filters, you can use convert=raid1,profiles=single,soft, which will take only the unconverted single profiles and convert them to raid1. This may speed up the conversion as it would not try to rewrite the already convert raid1 profiles.

Having just one profile is desired as this also clearly defines the profile of newly allocated block groups, otherwise this depends on internal allocation policy. When there are multiple profiles present, the order of selection is RAID56, RAID10, RAID1, RAID0 as long as the device number constraints are satisfied.

Commands that print the warning were chosen so they're brought to user attention when the filesystem state is being changed in that regard. This is: device add, device delete, balance cancel, balance pause. Commands that report space usage: filesystem df, device usage. The command filesystem usage provides a line in the overall summary:

Multiple profiles:                 yes (data, metadata)

DISPOZITIV DE ÎNSĂMÂNȚARE¶

The COW mechanism and multiple devices under one hood enable an interesting concept, called a seeding device: extending a read-only filesystem on a device with another device that captures all writes. For example imagine an immutable golden image of an operating system enhanced with another device that allows to use the data from the golden image and normal operation. This idea originated on CD-ROMs with base OS and allowing to use them for live systems, but this became obsolete. There are technologies providing similar functionality, like unionmount <https://en.wikipedia.org/wiki/Union_mount>, overlayfs <https://en.wikipedia.org/wiki/OverlayFS> or qcow2 <https://en.wikipedia.org/wiki/Qcow#qcow2> image snapshot.

The seeding device starts as a normal filesystem, once the contents is ready, btrfstune -S 1 is used to flag it as a seeding device. Mounting such device will not allow any writes, except adding a new device by btrfs device add. Then the filesystem can be remounted as read-write.

Given that the filesystem on the seeding device is always recognized as read-only, it can be used to seed multiple filesystems from one device at the same time. The UUID that is normally attached to a device is automatically changed to a random UUID on each mount.

Notă:

Before v6.17 kernel, a seed device could have been mounted independently along with sprouted filesystems. But since 6.17 kernel, a seed device can only be mounted either through a sprouted filesystem, or the seed device itself, not both at the same time.

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.

Once the seeding device is mounted, it needs the writable device. After adding it, unmounting and mounting with umount /path; mount /dev/writable /path or remounting read-write with remount -o remount,rw makes the filesystem at /path ready for use.

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.

The seeding device flag can be cleared again by btrfstune -f -S 0, e.g. allowing to update with newer data but please note that this will invalidate all existing filesystems that use this particular seeding device. This works for some use cases, not for others, and the forcing flag to the command is mandatory to avoid accidental mistakes.

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
umount /path; mount /dev/writable /path can be replaced with mount -o remount,rw /path but it won't reclaim space of deleted subvolumes until the seeding device is mounted read-write again before making it seeding again

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

Though it's not recommended and is rather an obscure and untested use case, chaining seeding devices is possible. In the first example, the writable device /dev/sdb can be turned onto another seeding device again, depending on the unchanged seeding device /dev/sda. Then using /dev/sdb as the primary seeding device it can be extended with another writable device, say /dev/sdd, and it continues as before as a simple tree structure on devices.

# 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¶

The RAID56 feature provides striping and parity over several devices, same as the traditional RAID5/6. There are some implementation and design deficiencies that make it unreliable for some corner cases and the feature should not be used in production, only for evaluation or testing. The power failure safety for metadata with RAID56 is not 100%.

Metadate¶

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

The substitute profiles provide the same guarantees against loss of 1 or 2 devices, and in some respect can be an improvement. Recovering from one missing device will only need to access the remaining 1st or 2nd copy, that in general may be stored on some other devices due to the way RAID1 works on btrfs, unlike on a striped profile (similar to raid0) that would need all devices all the time.

The space allocation pattern and consumption is different (e.g. on N devices): for raid5 as an example, a 1GiB chunk is reserved on each device, while with raid1 there's each 1GiB chunk stored on 2 devices. The consumption of each 1GiB of used metadata is then N * 1GiB for vs 2 * 1GiB. Using raid1 is also more convenient for balancing/converting to other profile due to lower requirement on the available chunk space.

Suport lipsă/incomplet¶

When RAID56 is on the same filesystem with different raid profiles, the space reporting is inaccurate, e.g. df, btrfs filesystem df or btrfs filesystem usage. When there's only a one profile per block group type (e.g. RAID5 for data) the reporting is accurate.

When scrub is started on a RAID56 filesystem, it's started on all devices that degrade the performance. The workaround is to start it on each device separately. Due to that the device stats may not match the actual state and some errors might get reported multiple times.

The write hole problem. An unclean shutdown could leave a partially written stripe in a state where the some stripe ranges and the parity are from the old writes and some are new. The information which is which is not tracked. Write journal is not implemented. Alternatively a full read-modify-write would make sure that a full stripe is always written, avoiding the write hole completely, but performance in that case turned out to be too bad for use.

The striping happens on all available devices (at the time the chunks were allocated), so in case a new device is added it may not be utilized immediately and would require a rebalance. A fixed configured stripe width is not implemented.

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: An operation that can be done to a btrfs filesystem, for example through btrfs balance /path. A balance passes all data in the filesystem through the allocator again. It is primarily intended to rebalance the data in the filesystem across the devices when a device is added or removed. A balance will regenerate missing copies for the redundant RAID levels, if a device has failed. As of Linux kernel 3.3, a balance operation can be made selective about which parts of the filesystem are rewritten using filters <#man-balance-filters>.
barrier: An instruction to the underlying hardware to ensure that everything before the barrier is physically written to permanent storage before anything after it. Used in btrfs's copy on write approach to ensure filesystem consistency.
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: The unit of allocation of space in btrfs. A block group is laid out on the disk by the btrfs allocator, and will consist of one or more chunks, each stored on a different device. The number of chunks used in a block group will depend on its RAID level.
B-tree: The fundamental storage data structure used in btrfs. Except for the superblocks, all of btrfs metadata is stored in one of several B-trees on disk. B-trees store key/item pairs. While the same code is used to implement all of the B-trees, there are a few different categories of B-tree. The name btrfs refers to its use of B-trees.
btrfsck, fsck, btrfs-check: Tool in btrfs-progs that checks an unmounted filesystem (offline) and reports on any errors in the filesystem structures it finds. By default the tool runs in read-only mode as fixing errors is potentially dangerous. See also scrub.
btrfs-progs: User mode tools to manage btrfs-specific features. Maintained at <http://github.com/kdave/btrfs-progs.git> . The main frontend to btrfs features is the standalone tool btrfs, although other tools such as mkfs.btrfs and btrfstune are also part of 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: Usually referred to in context of deleted subvolumes. It's a background process that removes the actual data once a subvolume has been deleted. Cleaning can involve lots of IO and CPU activity depending on the fragmentation and amount of shared data with other subvolumes.
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: Also known as COW. The method that btrfs uses for modifying data. Instead of directly overwriting data in place, btrfs takes a copy of the data, alters it, and then writes the modified data back to a different (unused) location on the disk. It then updates the metadata to reflect the new location of the data. In order to update the metadata, the affected metadata blocks are also treated in the same way. In COW filesystems, files tend to fragment as they are modified. Copy-on-write is also used in the implementation of snapshots and reflink copies. A copy-on-write filesystem is, in theory, always consistent, provided the underlying hardware supports 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: A standard Unix tool for reporting the amount of space used and free in a filesystem. The standard tool does not give accurate results, but the btrfs command from btrfs-progs has an implementation of df which shows space available in more detail. See the [[FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F|FAQ]] for a more detailed explanation of btrfs free space accounting.
DUP: A form of "RAID" which stores two copies of each piece of data on the same device. This is similar to RAID1, and protects against block-level errors on the device, but does not provide any guarantees if the entire device fails. By default, btrfs uses DUP profile for metadata on single device filesystem.s
ENOSPC: Error code returned by the OS to a user program when the filesystem cannot allocate enough data to fulfill the user request. In most filesystems, it indicates there is no free space available in the filesystem. Due to the additional space requirements from btrfs's COW behaviour, btrfs can sometimes return ENOSPC when there is apparently (in terms of df) a large amount of space free. This is effectively a bug in btrfs, and (if it is repeatable), using the mount option enospc_debug may give a report that will help the btrfs developers. See the [[FAQ#if_your_device_is_large_.28.3E16GiB.29|FAQ entry]] on free space.
extent: Contiguous sequence of bytes on disk that holds file data. It's a compact representation that tracks the start and length of the byte range, so the logic behind allocating blocks (delayed allocation) strives for maximizing the length before writing the extents to the devices.
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: Command line tool in util-linux, and a syscall, that reserves space in the filesystem for a file, without actually writing any file data to the filesystem. First data write will turn the preallocated extents into regular ones. See fallocate(1) <https://man7.org/linux/man-pages/man1/fallocate.1.html> and fallocate(2) <https://man7.org/linux/man-pages/man2/fallocate.2.html> manual pages for more details.
filefrag: A tool to show the number of extents in a file, and hence the amount of fragmentation in the file. It is usually part of the e2fsprogs package on most Linux distributions. While initially developed for the ext2 filesystem, it works on Btrfs as well. It uses the FIEMAP ioctl.
free space cache: Also known as "space cache v1". A separate cache tracking free space as btrfs only tracks the allocated space. The free space is by definition any hole between allocated ranges. Finding the free ranges can be I/O intensive so the cache stores a condensed representation of it. It is updated every transaction commit.
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: On Unix and Unix-like operating systems (of which Linux is the latter), the fsync(2) <https://man7.org/linux/man-pages/man2/fsync.2.html> system call causes all buffered file descriptor related data changes to be flushed to the underlying block device. When a file is modified on a modern operating system the changes are generally not written to the disk immediately but rather those changes are buffered in memory for performance reasons, calling fsync(2) <https://man7.org/linux/man-pages/man2/fsync.2.html> causes any in-memory changes to be written to disk.
generation: An internal counter which updates for each transaction. When a metadata block is written (using copy on write), current generation is stored in the block, so that blocks which are too new (and hence possibly inconsistent) can be identified.
key: A fixed sized tuple used to identify and sort items in a B-tree. The key is broken up into 3 parts: objectid, type, and offset. The type field indicates how each of the other two fields should be used, and what to expect to find in the item.
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: A class of different methods for writing some additional redundant data across multiple devices so that if one device fails, the missing data can be reconstructed from the remaining ones. See RAID0, RAID1, RAID5, RAID6, RAID10, DUP and single. Traditional RAID methods operate across multiple devices of equal size, whereas btrfs' RAID implementation works inside block groups.
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: A form of RAID which stores two/three/four complete copies of each piece of data. Each copy is stored on a different device. btrfs requires a minimum of two devices to use RAID-1 or three/four respectively. This is the default block group profile for btrfs's metadata on more than one device.
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: Commonly used as a reference to a shallow copy of file extents that share the extents until the first change. Reflinked files (e.g. by the cp) are different files but point to the same extents, any change will be detected and new copy of the data created, keeping the files independent. Related to that is extent range cloning, that works on a range of a file.
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 <>: A readonly device can be used as a filesystem seed or template (e.g. a CD-ROM containing an OS image). Read/write devices can be added to store modifications (using copy on write), changes to the writable devices are persistent across reboots. The original device remains unchanged and can be removed at any time (after Btrfs has been instructed to copy over all missing blocks). Multiple read/write file systems can be built from the same seed.
single: Un profil de grup de blocuri care stochează o singură copie a fiecărei informații.
snapshot <>: A subvolume which is a copy on write copy of another subvolume. The two subvolumes share all of their common (unmodified) data, which means that snapshots can be used to keep the historical state of a filesystem very cheaply. After the snapshot is made, the original subvolume and the snapshot are of equal status: the original does not "own" the snapshot, and either one can be deleted without affecting the other one.
subvolume <>: A tree of files and directories inside a btrfs that can be mounted as if it were an independent filesystem. A subvolume is created by taking a reference on the root of another subvolume. Each btrfs filesystem has at least one subvolume, the top-level subvolume, which contains everything else in the filesystem. Additional subvolumes can be created and deleted with the btrfs< tool. All subvolumes share the same pool of free space in the filesystem. See also default subvolume.
super block: A special metadata block that is a main access point of the filesystem structures. It's size is fixed and there are fixed locations on the devices used for detecting and opening the filesystem. Updating the superblock defines one transaction. The super blocks contains filesystem identification (UUID), checksum type, block pointers to fundamental trees, features and creation parameters.
system array: A technical term for super block metadata describing how to assemble a filesystem from multiple device, storing information about chunks and devices that are required to be scanned/registered at the time the mount happens. Scanning is done by command btrfs device scan, alternatively all the required devices can be specified by a mount option device=/path.
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: A consistent set of changes. To avoid generating very large amounts of disk activity, btrfs caches changes in RAM for up to 30 seconds (sometimes more often if the filesystem is running short on space or doing a lot of fsync*s), and then writes (commits) these changes out to disk in one go (using *copy on write behaviour). This period of caching is called a transaction. Only one transaction is active on the filesystem at any one time.
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.

The filesystem assumes several features or limitations of the storage device and utilizes them or applies measures to guarantee reliability. BTRFS in particular is based on a COW (copy on write) mode of writing, i.e. not updating data in place but rather writing a new copy to a different location and then atomically switching the pointers.

In an ideal world, the device does what it promises. The filesystem assumes that this may not be true so additional mechanisms are applied to either detect misbehaving hardware or get valid data by other means. The devices may (and do) apply their own detection and repair mechanisms but we won't assume any.

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

The consistency model of BTRFS builds on these assumptions. The logical data updates are grouped, into a generation, written on the device, serialized by the flush command and then the super block is written ending the generation. All logical links among metadata comprising a consistent view of the data may not cross the generation boundary.

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)

This is perhaps the most serious problem and impossible to mitigate by filesystem without limitations and design restrictions. What could happen in the worst case is that writes from one generation bleed to another one, while still letting the filesystem consider the generations isolated. Crash at any point would leave data on the device in an inconsistent state without any hint what exactly got written, what is missing and leading to stale metadata link information.

Devices usually honor the flush command, but for performance reasons may do internal caching, where the flushed data are not yet persistently stored. A power failure could lead to a similar scenario as above, although it's less likely that later writes would be written before the cached ones. This is beyond what a filesystem can take into account. Devices or controllers are usually equipped with batteries or capacitors to write the cache contents even after power is cut. (Battery backed write cache)

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ă).

The metadata blocks have the checksum embedded in the blocks, so a correct atomic write would not corrupt the checksum. It's likely that after reading such block the data inside would not be consistent with the rest. To rule that out there's embedded block number in the metadata block. It's the logical block number because this is what the logical structure expects and verifies.

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ă¶

The data structures and raw data blocks are temporarily stored in computer memory before they get written to the device. It is critical that memory is reliable because even simple bit flips can have vast consequences and lead to damaged structures, not only in the filesystem but in the whole operating system.

Based on experience in the community, memory bit flips are more common than one would think. When it happens, it's reported by the tree-checker or by a checksum mismatch after reading blocks. There are some very obvious instances of bit flips that happen, e.g. in an ordered sequence of keys in metadata blocks. We can easily infer from the other data what values get damaged and how. However, fixing that is not straightforward and would require cross-referencing data from the entire filesystem to see the scope.

If available, ECC memory should lower the chances of bit flips, but this type of memory is not available in all cases. A memory test should be performed in case there's a visible bit flip pattern, though this may not detect a faulty memory module because the actual load of the system could be the factor making the problems appear. In recent years attacks on how the memory modules operate have been demonstrated (rowhammer) achieving specific bits to be flipped. While these were targeted, this shows that a series of reads or writes can affect unrelated parts of memory.

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ă.

A filesystem mounted read-only will not affect the underlying block device in almost 100% (with highly unlikely exceptions). The exception is a tree-log that needs to be replayed during mount (and before the read-only mount takes place), working memory is needed for that and that can be affected by bit flips. There's a theoretical case where bit flip changes the filesystem status from read-only to read-write.

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)¶

Another class of errors is related to DMA (direct memory access) performed by device drivers. While this could be considered a software error, the data transfers that happen without CPU assistance may accidentally corrupt other pages. Storage devices utilize DMA for performance reasons, the filesystem structures and data pages are passed back and forth, making errors possible in case page life time is not properly tracked.

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)¶

Rotational HDDs typically fail at the level of individual sectors or small clusters. Read failures are caught on the levels below the filesystem and are returned to the user as EIO - Input/output error. Reading the blocks repeatedly may return the data eventually, but this is better done by specialized tools and filesystem takes the result of the lower layers. Rewriting the sectors may trigger internal remapping but this inevitably leads to data loss.

Disk firmware is technically software but from the filesystem perspective is part of the hardware. IO requests are processed, and caching or various other optimizations are performed, which may lead to bugs under high load or unexpected physical conditions or unsupported use cases.

Disks are connected by cables with two ends, both of which can cause problems when not attached properly. Data transfers are protected by checksums and the lower layers try hard to transfer the data correctly or not at all. The errors from badly-connecting cables may manifest as large amount of failed read or write requests, or as short error bursts depending on physical conditions.

Ce trebuie făcut:

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

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

The mechanism of information storage is different from HDDs and this affects the failure mode as well. The data are stored in cells grouped in large blocks with limited number of resets and other write constraints. The firmware tries to avoid unnecessary resets and performs optimizations to maximize the storage media lifetime. The known techniques are deduplication (blocks with same fingerprint/hash are mapped to same physical block), compression or internal remapping and garbage collection of used memory cells. Due to the additional processing there are measures to verify the data e.g. by ECC codes.

The observations of failing SSDs show that the whole electronic fails at once or affects a lot of data (e.g. stored on one chip). Recovering such data may need specialized equipment and reading data repeatedly does not help as it's possible with HDDs.

There are several technologies of the memory cells with different characteristics and price. The lifetime is directly affected by the type and frequency of data written. Writing "too much" distinct data (e.g. encrypted) may render the internal deduplication ineffective and lead to a lot of rewrites and increased wear of the memory cells.

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

Only users who consume 50 to 100% of the SSD's actual lifetime writes need to be concerned by the write amplification of btrfs DUP metadata. Most users will be far below 50% of the actual lifetime, or will write the drive to death and discover how many writes 100% of the actual lifetime was. SSD firmware often adds its own write multipliers that can be arbitrary and unpredictable and dependent on application behavior, and these will typically have far greater effect on SSD lifespan than DUP metadata. It's more or less impossible to predict when a SSD will run out of lifetime writes to within a factor of two, so it's hard to justify wear reduction as a benefit.

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 is a type of persistent memory usually connected over a system bus (PCIe) or similar interface and the speeds are an order of magnitude faster than SSD. It is also a non-rotating type of storage, and is not typically connected by a cable. It's not a SCSI type device either but rather a complete specification for logical device interface.

Î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ă.

There are separate error detection and correction steps performed e.g. on the bus level and in most cases never making in to the filesystem level. Once this happens it could mean there's some systematic error like overheating or bad physical connection of the device. You may want to run self-tests (using smartctl).

Firmware pentru unitate¶

Firmware is technically still software but embedded into the hardware. As all software has bugs, so does firmware. Storage devices can update the firmware and fix known bugs. In some cases the it's possible to avoid certain bugs by quirks (device-specific workarounds) in Linux kernel.

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¶

There are a lot of devices with low power consumption and thus using storage media based on low power consumption too, typically flash memory stored on a chip enclosed in a detachable card package. An improperly inserted card may be damaged by electrical spikes when the device is turned on or off. The chips storing data in turn may be damaged permanently. All types of flash memory have a limited number of rewrites, so the data are internally translated by FTL (flash translation layer). This is implemented in firmware (technically a software) and prone to bugs that manifest as hardware errors.

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) <https://man7.org/linux/man-pages/man5/acl.5.html>, btrfs(8) <>, chattr(1) <https://man7.org/linux/man-pages/man1/chattr.1.html>, fstrim(8) <https://man7.org/linux/man-pages/man8/fstrim.8.html>, ioctl(2) <https://man7.org/linux/man-pages/man2/ioctl.2.html>, btrfs-ioctl(2) <>, mkfs.btrfs(8) <>, mount(8) <https://man7.org/linux/man-pages/man8/mount.8.html>, swapon(8) <https://man7.org/linux/man-pages/man8/swapon.8.html>

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.

7 noiembrie 2025

6.17.1

Source file:	btrfs.5.ro.gz (from manpages-ro 4.30.0-1)
Source last updated:	2026-03-30T11:00:51Z
Converted to HTML:	2026-04-06T20:48:14Z