BTRFS(5)

BTRFS

BTRFS(5)

NUME¶

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

DESCRIERE¶

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

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

OPȚIUNI DE MONTARE¶

OPȚIUNI DE MONTARE SPECIFICE PENTRU BTRFS¶

This section describes mount options specific to BTRFS. For the generic mount options please refer to mount(8) manual page and also see the section with BTRFS specifics below. The options are sorted alphabetically (discarding the no prefix).

NOTĂ:

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

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

acl, noacl

(implicit: activată)

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

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

autodefrag, noautodefrag

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

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

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

AVERTISMENT:

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

barrier, nobarrier

(implicit: activată)

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

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

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

clear_cache

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

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

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

A se vedea, de asemenea: space_cache.

commit=<secunde>

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

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

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

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

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

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

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

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

NOTĂ:

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

datacow, nodatacow

(implicit: activată)

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

NOTĂ:

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

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

datasum, nodatasum

(implicit: activată)

Enable data checksumming for newly created files. Datasum implies datacow, i.e. the normal mode of operation. All files created under nodatasum inherit the "no checksums" property, however there's no corresponding file attribute (see chattr(1)).

NOTĂ:

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

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

degraded

(implicit: dezactivată)

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

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

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

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

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

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

discard, discard=sync, discard=async, nodiscard

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

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

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

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

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

enospc_debug, noenospc_debug

(implicit: dezactivată)

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

fatal_errors=<acțiune>

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

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

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

flushoncommit, noflushoncommit

(implicit: dezactivată)

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

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

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

fragment=<tip>

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

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

nologreplay

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

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

AVERTISMENT:

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

max_inline=<octeți>

(implicit: min(2048, dimensiunea paginii) )

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

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

NOTĂ:

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

metadata_ratio=<valoare>

(implicit: 0, logică internă)

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

norecovery

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

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

NOTĂ:

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

rescan_uuid_tree: (începând cu: 3.12, implicit: dezactivată)
Force check and rebuild procedure of the UUID tree. This should not normally be needed. Alternatively the tree can be cleared from userspace by command btrfs rescue clear-uuid-tree and then it will be automatically rebuilt in kernel (the mount option is not needed in that case).
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Ă:

Historically, any user could create a snapshot even if he was not owner of the source subvolume, the subvolume deletion has been restricted for that reason. The subvolume creation has been restricted but this mount option is still required. This is a usability issue. Since 4.18, the rmdir(2) syscall can delete an empty subvolume just like an ordinary directory. Whether this is possible can be detected at runtime, see rmdir_subvol feature in FILESYSTEM FEATURES.

OPȚIUNI DE MONTARE DEPRECIATE¶

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

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

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

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

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

check_int, check_int_data, check_int_print_mask=<valoare>

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

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

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

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

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

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

NOTE PRIVIND OPȚIUNILE DE MONTARE GENERICE¶

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

context: Contextul se referă la contextele SELinux și la definițiile politicilor transmise ca opțiuni de montare. Acest lucru funcționează corect începând cu versiunea v6.8 (deoarece analizatorul opțiunilor de montare din BTRFS a fost adaptat la noul API care înțelege și opțiunile).
noatime: under read intensive work-loads, specifying noatime significantly improves performance because no new access time information needs to be written. Without this option, the default is relatime, which only reduces the number of inode atime updates in comparison to the traditional strictatime. The worst case for atime updates under relatime occurs when many files are read whose atime is older than 24 h and which are freshly snapshotted. In that case the atime is updated and COW happens - for each file - in bulk. See also 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 sumă de control. Pentru mai multe detalii, consultați mkfs.btrfs(8).
după mkfs, pe un sistem de fișiere nemontat: Features that may optimize internal structures or add new structures to support new functionality, see btrfstune(8). The command btrfs inspect-internal dump-super /dev/sdx will dump a superblock, you can map the value of incompat_flags to the features listed below
după mkfs, pe un sistem de fișiere montat: Caracteristicile unui sistem de fișiere (cu un anumit UUID) sunt enumerate în /sys/fs/btrfs/UUID/features/, câte un fișier pentru fiecare caracteristică. Starea este stocată în interiorul fișierului. Valoarea 1 indică faptul că caracteristica este activată și funcțională, în timp ce 0 înseamnă că caracteristica a fost activată la montare, dar a fost dezactivată ulterior.
În directorul /sys/fs/btrfs/features/ se poate afla dacă o anumită caracteristică poate fi activată pe un sistem de fișiere montat, un fișier pentru fiecare caracteristică. Valoarea 1 înseamnă că funcția poate fi activată.

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

big_metadata

(începând cu: 3.4)

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

block_group_tree

(începând cu: 6.1)

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

compress_lzo

(începând cu: 2.6.38)

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

compress_zstd

(începând cu: 4.14)

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

default_subvol

(începând cu: 2.6.34)

subvolumul implicit a fost definit pe sistemul de fișiere

extended_iref

(începând cu: 3.7)

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

free_space_tree

(începând cu: 4.5)

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

metadata_uuid

(începând cu: 5.0)

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

mixed_backref

(începând cu: 2.6.31)

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

mixed_groups

(începând cu: 2.6.37)

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

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

no_holes

(începând cu: 3.14)

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

raid1c34

(începând cu: 5.5)

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

raid_stripe_tree

(începând cu: 6.7)

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

RAID56

(începând cu: 3.9)

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

rmdir_subvol

(începând cu: 4.18)

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

skinny_metadata

(începând cu: 3.10)

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

send_stream_version

(începând cu: 5.10)

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

simple_quota

(începând cu: 6.7)

contabilizarea simplificată a cotelor

supported_checksums

(începând cu: 5.5)

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

supported_sectorsizes

(începând cu: 5.13)

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

supported_rescue_options

(începând cu: 5.11)

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

zoned

(începând cu Linux 5.12)

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

SUPORT PENTRU FIȘIERUL DE INTERSCHIMB (SWAP)¶

A swapfile, when active, is a file-backed swap area. It is supported since kernel 5.0. Use swapon(8) to activate it, until then (respectively again after deactivating it with swapoff(8)) it's just a normal file (with NODATACOW set), for which the special restrictions for active swapfiles don't apply.

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.

Since version 6.1 there's a command btrfs inspect-internal map-swapfile that will print the device physical offset and the adjusted value for /sys/power/resume_offset. Note that the value is divided by page size, i.e. it's not the offset itself.

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

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

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

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

SOLUȚIONAREA PROBLEMELOR¶

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

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

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

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

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

ALGORITMI DE SUMĂ DE CONTROL¶

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

NOTĂ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

COMPRIMARE¶

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

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

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

ZLIB

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

LZO

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

ZSTD

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

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

CUM SE ACTIVEAZĂ COMPRIMAREA¶

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

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

$ btrfs filesystem defrag -czstd fișier

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

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

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

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

NIVELURI DE COMPRIMARE¶

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

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

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

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

EXCEPȚIII¶

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

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

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

DATE INCOMPREHENSIBILE¶

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

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

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

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

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

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

EURISTICI PRE-COMPRIMARE¶

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

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

COMPATIBILITATE¶

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

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

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

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

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

INTERFAȚA SYSFS¶

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

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

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

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

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

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

UUID¶

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

bg_reclaim_threshold

(RW, începând cu: 5.19)

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

checksum

(RO, începând cu: 5.5)

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

clone_alignment

(RO, începând cu: 3.16)

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

commit_stats

(RW, începând cu: 6.0)

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

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

commits 70649
last_commit_ms 2
max_commit_ms 131
total_commit_ms 170840

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

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

UUID/allocations¶

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

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

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

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

bg_reclaim_threshold

(RW, începând cu: 5.19)

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

bytes_*

(RO)

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

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

chunk_size

(RW, începând cu: 6.0)

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

size_classes

(RO, începând cu: 6.3)

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

none 136
small 374
medium 282
large 93

UUID/bdi¶

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

UUID/devices¶

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

UUID/devinfo¶

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

UUID/devinfo/ID_DISPOZITIV¶

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

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

write_errs 0
read_errs 0
flush_errs 0
corruption_errs 0
generation_errs 0

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

UUID/qgroups¶

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

enabled

(RO, începând cu: 6.1)

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

inconsistent

(RO, începând cu: 6.1)

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

drop_subtree_threshold

(RW, începând cu: 6.1)

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

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

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

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

UUID/qgroups/ID_NIVEL¶

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

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

UUID/discard¶

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

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

OPERAȚII EXCLUSIVE ALE SISTEMULUI DE FIȘIERE¶

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

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

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

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

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

LIMITE ALE SISTEMULUI DE FIȘIERE¶

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

SUPORT PENTRU ÎNCĂRCĂTORUL DE PORNIRE¶

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

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

In general, the first 1MiB on each device is unused with the exception of primary superblock that is on the offset 64KiB and spans 4KiB. The rest can be freely used by bootloaders or for other system information. Note that booting from a filesystem on zoned device is not supported.

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:

attributes: chattr(1) or lsattr(1) utilities (the ioctls are FS_IOC_GETFLAGS and FS_IOC_SETFLAGS), due to the ioctl names the attributes are also called flags
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) as command xfs_io -c chattr

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

Atribute¶

a

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

A

(fișier, director) no atime updates

c

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

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

C

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

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

NOTĂ:

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

d: (fișier) no dump, are sens cu instrumente terțe precum dump(8), pe BTRFS atributul poate fi activat/dezactivat, dar nu se fac alte manipulări speciale
D: (director) synchronous directory updates, pentru mai multe detalii căutați open(2) pentru O_SYNC și O_DSYNC
i: (fișier, director, root) immutable, nicio modificare a datelor și metadatelor fișierelor nu este permisă nici măcar utilizatorului root atâta timp cât acest atribut este activat (evident, excepția este dezactivarea atributului)
m: (file, dir) no compression, permanently turn off compression on the given file. Any compression mount options will not affect this file. (chattr(1) support added in 1.46.2)
Atunci când este definit pentru un director, toate fișierele nou create vor moșteni acest atribut. Acest atribut nu poate fi definit în același timp cu c.
S: (fișier) synchronous updates, pentru mai multe detalii căutați open(2) pentru O_SYNC și O_DSYNC
V: (fișier, numai-citire) fs-verity enabled pe fișier

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

XFLAGS¶

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

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

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

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¶

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

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

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

Recuperarea zonei, colectarea gunoiului¶

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

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

Dispozitive¶

Hardware real¶

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

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

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

Emulat: null_blk¶

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

Configurarea:

modprobe configfs
modprobe null_blk nr_devices=0

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

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

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

Eliminați dispozitivul:

rmdir /sys/kernel/config/nullb/mydev

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

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

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

Emulat: runner (executor) TCMU¶

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

Stare, stabilitate, raportarea erorilor¶

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

Referințe¶

•: https://zonedstorage.io

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

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

DISPOZITIV DE CONTROL¶

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

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

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

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

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

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

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

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

# btrfs rescue create-control-device

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

SISTEM DE FIȘIERE CU PROFILURI MULTIPLE¶

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.

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

NOTĂ:

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

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

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

Multiple profiles:                 yes (data, metadata)

DISPOZITIV DE ÎNSĂMÂNȚARE¶

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, overlayfs or qcow2 image snapshot.

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

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

NOTĂ:

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

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

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

NOTĂ:

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

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

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

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

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

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

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

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

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

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

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

Câteva lucruri de reținut:

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

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

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

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

Ca rezultat, avem:

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

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

STAREA RAID56 ȘI PRACTICI RECOMANDATE¶

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

Metadate¶

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

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

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

Suport lipsă/incomplet¶

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

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

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

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

GLOSAR¶

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

allocator: De obicei, allocator înseamnă alocatorul block, adică logica din interiorul sistemului de fișiere care decide unde să plaseze blocurile nou alocate pentru a menține mai multe constrângeri (precum amplasarea datelor, fragmentarea redusă).
În btrfs, alocatorul se poate referi și la alocatorul chunk, adică logica din spatele plasării bucăților pe dispozitive.
balance: 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.
barrier: O instrucțiune adresată hardware-ului subiacent pentru a se asigura că toate datele situate înaintea barierei sunt scrise fizic pe suportul de stocare permanent înaintea celor situate după aceasta. Se utilizează în cadrul abordării copy on write a sistemului de fișiere Btrfs pentru a asigura coerența sistemului de fișiere.
block: O singură piesă de stocare contiguă din punct de vedere fizic și logic pe un dispozitiv, de dimensiune, de exemplu, 4K. În unele contexte, se face referire și la sector, deși este preferat termenul block.
block group: Unitatea de alocare a spațiului în Btrfs. Un grup de blocuri este configurat pe disc de către alocatorul Btrfs și va consta dintr-unul sau mai multe chunks (fragmente), fiecare fiind stocat pe un dispozitiv diferit. Numărul de chunks-uri utilizate într-un grup de blocuri va depinde de nivelul său RAID.
B-tree: Structura fundamentală de stocare a datelor utilizată în btrfs. Cu excepția superblocurilor, toate metadatele btrfs sunt stocate într-unul dintre numeroșii arbori-B (B-trees) de pe disc. Arborii-B stochează perechi cheie/element. Deși se folosește același cod pentru implementarea tuturor arborilor-B, există câteva categorii diferite de arbori-B. Denumirea „btrfs” se referă la utilizarea arborilor-B.
btrfsck, fsck, btrfs-check: Instrument din pachetul btrfs-progs care verifică un sistem de fișiere nemontat (offline) și raportează eventualele erori identificate în structurile sistemului de fișiere. În mod implicit, instrumentul rulează în modul numai-citire, deoarece remedierea erorilor poate fi periculoasă. A se vedea de asemenea scrub.
btrfs-progs: 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: Termenul este folosit de obicei în contextul subvolumelor șterse. Este vorba despre un proces care rulează în fundal și care elimină datele propriu-zise odată ce un subvolum a fost șters. Procesul de curățare poate implica o activitate intensă la nivel de operații de In/Ieș și CPU, în funcție de gradul de fragmentare și de cantitatea de date partajate cu alte subvolume.
Firul de execuție mai curat al nucleului procesează, de asemenea, defragmentarea declanșată de opțiunea de montare autodefrag, eliminarea grupurilor de blocuri goale și alte câteva sarcini de finalizare.
copy-on-write, COW: Cunoscută și sub denumirea de COW. Metoda utilizată de btrfs pentru modificarea datelor. În loc să suprascrie direct datele în locația inițială, btrfs realizează o copie a datelor, o modifică și apoi scrie datele modificate într-o altă locație (neutilizată) de pe disc. Apoi actualizează metadatele pentru a reflecta noua locație a datelor. Pentru a actualiza metadatele, blocurile de metadate afectate sunt tratate în același mod. În sistemele de fișiere COW, fișierele tind să se fragmenteze pe măsură ce sunt modificate. Metoda copy-on-write este utilizată și în implementarea snapshots și reflink copies. Un sistem de fișiere copy-on-write este, în teorie, întotdeauna consistent, cu condiția ca hardware-ul subiacent să accepte barriers.
default subvolume: sub-volumul dintr-un sistem de fișiere btrfs care este montat la montarea sistemului de fișiere fără a utiliza opțiunea de montare subvol=.
device: Un dispozitiv de blocuri Linux, de exemplu, un disc întreg, o partiție, un volum logic LVM, un dispozitiv loopback sau un dispozitiv de blocuri de rețea. Un sistem de fișiere btrfs poate rezida pe unul sau mai multe dispozitive.
df: 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) and fallocate(2) 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) 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) 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), btrfs(8), chattr(1), fstrim(8), ioctl(2), btrfs-ioctl(2), mkfs.btrfs(8), mount(8), swapon(8)

TRADUCERE¶

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

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

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

13 februarie 2026

6.19

Source file:	btrfs.5.ro.gz (from man-pages-ro 4.30.2-1.1)
Source last updated:	2026-05-15T16:18:45Z
Converted to HTML:	2026-05-17T01:01:12Z