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. In prezent acopera:

       1.  op<?>iuni de montare

       2.  caracteristici ale sistemului de fi<?>iere

       3.  suport pentru fi<?>ierul de interschimb (swap)

       4.  algoritmi de suma de control

       5.  comprimare

       6.  interfa<?>a sysfs

       7.  opera<?>ii exclusive ale sistemului de fi<?>iere

       8.  limite ale sistemului de fi<?>iere

       9.  suport pentru incarcatorul de pornire

       10. atribute de fi<?>ier

       11. modul zonat

       12. dispozitiv de control

       13. sisteme de fi<?>iere cu mai multe profiluri de grupuri de blocuri

       14. dispozitiv de insaman<?>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
       Aceasta sec<?>iune descrie op<?>iunile de montare specifice sistemului
       de fi<?>iere BTRFS.  Pentru op<?>iunile generice de montare,
       consulta<?>i pagina de manual mount(8) <https://man7.org/linux/
       man-pages/man8/mount.8.html> <?>i consulta<?>i, de asemenea,
       sec<?>iunea cu detalii specifice BTRFS de mai jos <btrfs-man5//#
        mount-options-generic>. Op<?>iunile sunt sortate alfabetic (fara
       prefixul no).

       Nota:
          Majoritatea op<?>iunilor de montare se aplica intregului sistem de
          fi<?>iere, iar numai op<?>iunile din primul subvolum montat vor
          produce efect. Acest lucru se datoreaza lipsei unei implementari
          adecvate <?>i se poate schimba in viitor. Aceasta inseamna ca (de
          exemplu) nu pute<?>i defini op<?>iunile nodatacow, nodatasum sau
          compress pentru fiecare subvolum in parte folosind op<?>iunile de
          montare. Aceasta problema ar trebui rezolvata in cele din urma, dar
          s-a dovedit a fi dificil de implementat corect in cadrul sistemului
          VFS din Linux.

       Op<?>iunile de montare sunt procesate in 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 arata ce op<?>iuni au fost
       aplicate.

       acl, noacl
              (implicit: activata)

              Activeaza/dezactiveaza suportul pentru listele de control al
              accesului POSIX (ACL). Consulta<?>i pagina manualului acl(5)
              <https://man7.org/linux/man-pages/man5/acl.5.html> pentru mai
              multe informa<?>ii despre ACL.

              Suportul pentru ACL este configurabil in timpul compilarii
              (BTRFS_FS_POSIX_ACL) <?>i montarea e<?>ueaza daca se solicita
              acl, dar func<?>ia nu este compilata.

       autodefrag, noautodefrag
              (incepand cu: 3.0, implicit: dezactivata)

              Activeaza defragmentarea automata a fi<?>ierelor. Cand aceasta
              op<?>iune este activata, opera<?>iile mici de scriere aleatorie
              in fi<?>iere (cu o dimensiune de cateva zeci de kiloocte<?>i, in
              prezent aproximativ 64 Kio) sunt detectate <?>i puse in coada
              pentru procesul de defragmentare. Este posibil ca aceasta
              op<?>iune sa nu fie potrivita pentru sarcini de lucru cu baze de
              date de mari dimensiuni.

              Laten<?>a de citire poate cre<?>te din cauza citirii blocurilor
              adiacente care alcatuiesc intervalul pentru defragmentare, iar
              scrierea succesiva va fuziona blocurile in 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 legaturile de referin<?>a
                 ale datelor COW (de exemplu, fi<?>iere copiate cu <<cp
                 --reflink>>, instantanee sau date deduplicate).  Acest lucru
                 poate duce la o cre<?>tere considerabila a spa<?>iului
                 utilizat, in func<?>ie de legaturile de referin<?>a rupte.

       barrier, nobarrier
              (implicit: activata)

              Se asigura ca toate opera<?>iile de scriere de In/Ie<?> trec
              prin memoria cache a dispozitivului <?>i sunt stocate definitiv
              atunci cand sistemul de fi<?>iere se afla la punctul de
              verificare a consisten<?>ei. De obicei, aceasta inseamna ca se
              trimite o comanda de golire catre dispozitiv, care va sincroniza
              toate datele in a<?>teptare <?>i blocurile de metadate
              obi<?>nuite, apoi va scrie super-blocul <?>i va emite o alta
              comanda de golire.

              Opera<?>iile de scriere cu validare (write-flush) genereaza o
              u<?>oara penalizare <?>i impiedica, de asemenea, programatorul
              de blocuri de In/Ie<?> sa reordoneze cererile intr-un mod mai
              eficient. Dezactivarea barierelor elimina aceasta penalizare,
              dar va duce cu siguran<?>a la coruperea sistemului de fi<?>iere
              in cazul unei blocari sau al unei intreruperi de curent.
              Blocurile obi<?>nuite de metadate ar putea sa nu fie inca scrise
              in momentul in care noul super-bloc este stocat definitiv,
              presupunand ca indicatorii de bloc catre metadate au fost
              stoca<?>i permanent inainte.

              Pe un dispozitiv cu o memorie cache volatila, alimentat de la
              baterie, op<?>iunea nobarrier nu va duce la coruperea sistemului
              de fi<?>iere, deoarece blocurile in a<?>teptare ar trebui sa
              ajunga in memoria permanenta.

       clear_cache
              For<?>eaza <?>tergerea <?>i reconstruirea cache-ului spa<?>iului
              liber daca ceva nu a func<?>ionat corect.

              In cazul cache-ului de spa<?>iu liber v1, aceasta op<?>iune doar
              <?>terge (<?>i, daca nu se utilizeaza nospace_cache,
              reconstruie<?>te) cache-ul de spa<?>iu liber pentru grupurile de
              blocuri modificate in timp ce sistemul de fi<?>iere este montat
              cu aceasta op<?>iune. Pentru a <?>terge efectiv intregul cache
              de spa<?>iu liber v1, consulta<?>i btrfs check
              --clear-space-cache v1.

              Pentru cache-ul spa<?>iului liber v2, aceasta <?>terge intregul
              cache al spa<?>iului liber. Pentru a face acest lucru fara a fi
              necesara montarea sistemului de fi<?>iere, consulta<?>i btrfs
              check --clear-space-cache v2.

              A se vedea, de asemenea: space_cache.

       commit=<secunde>
              (incepand cu: 3.12, implicit: 30)

              Stabile<?>te intervalul de efectuare periodica a tranzac<?>iilor
              atunci cand datele sunt sincronizate cu spa<?>iul de stocare
              permanent. Valorile mai mari ale intervalului duc la acumularea
              in memorie a unei cantita<?>i mai mari de date nescrise, ceea ce
              are consecin<?>e evidente in cazul unei blocari a sistemului.
              Limita superioara nu este impusa, dar se afi<?>eaza un
              avertisment daca aceasta depa<?>e<?>te 300 de secunde (5
              minute). A se utiliza cu precau<?>ie.

              Efectuarea periodica nu este singurul mecanism de efectuare a
              tranzac<?>iei; aceasta poate avea loc <?>i prin comanda
              explicita sync sau indirect, prin alte comenzi care afecteaza
              starea globala a sistemului de fi<?>iere sau prin mecanisme
              interne ale nucleului care efectueaza golirea memoriei in
              func<?>ie de diverse praguri sau politici (de exemplu, cgroups).

       compress, compress=<tip[:nivel]>, compress-force,
       compress-force=<tip[:nivel]>
              (implicit: dezactivata, suport pentru niveluri incepand cu: 5.1)

              Controleaza comprimarea datelor din fi<?>ierele BTRFS. Tipul
              poate fi specificat ca zlib, lzo, zstd sau no (pentru fara
              comprimare, utilizat la remontare). Daca nu se specifica niciun
              tip, se utilizeaza zlib. Daca se specifica compress-force, se va
              incerca intotdeauna comprimarea, dar datele pot ramane
              necomprimate daca comprimarea ar mari dimensiunea lor.

              Atat zlib, cat <?>i zstd (incepand cu versiunea 5.1) permit
              reglarea nivelului de comprimare, nivelurile mai ridicate
              sacrificand viteza <?>i memoria (zstd) in favoarea unor rapoarte
              de comprimare mai mari. Aceasta se poate regla prin adaugarea a
              doua puncte (:) urmate de nivelul dorit.  ZLIB accepta
              intervalul [1, 9], iar ZSTD accepta [1, 15]. Daca nu este
              definit niciun nivel, ambele utilizeaza in prezent un nivel
              implicit de 3. Valoarea 0 este un alias pentru nivelul implicit.

              In caz contrar, se aplica cateva metode euristice simple pentru
              a detecta un fi<?>ier necomprimabil. Daca primele blocuri scrise
              intr-un fi<?>ier nu sunt comprimabile, intregul fi<?>ier este
              marcat definitiv pentru a fi omis din procesul de comprimare.
              Deoarece aceasta abordare este prea simplista, op<?>iunea
              compress-force reprezinta o solu<?>ie de compromis care va
              comprima majoritatea fi<?>ierelor, cu pre<?>ul unor cicluri de
              procesor irosite in incercarile e<?>uate.  Incepand cu versiunea
              4.15 a nucleului, un set de algoritmi euristici a fost
              imbunata<?>it prin utilizarea e<?>antionarii de frecven<?>a, a
              detectarii modelelor repetate <?>i a calculului entropiei
              Shannon pentru a evita acest lucru.

              Nota:
                 Daca comprimarea este activata, nodatacow <?>i nodatasum sunt
                 dezactivate.

       datacow, nodatacow
              (implicit: activata)

              Activeaza copierea datelor la scriere pentru fi<?>ierele nou
              create.  Nodatacow implica nodatasum <?>i dezactiveaza
              compression. Toate fi<?>ierele create sub nodatacow au, de
              asemenea, atributul de fi<?>ier NOCOW (consulta<?>i chattr(1)
              <https://man7.org/linux/man-pages/man1/chattr.1.html>).

              Nota:
                 Daca nodatacow sau nodatasum sunt activate, comprimarea este
                 dezactivata.

              Actualizarile efectuate pe loc ,,direct" (fara utilizarea de
              tampoane, fi<?>iere temporale pentru stocarea datelor)
              imbunata<?>esc performan<?>a pentru volumele de lucru care
              efectueaza suprascrieri frecvente, cu pre<?>ul unor poten<?>iale
              scrieri par<?>iale, in cazul in care scrierea este intrerupta
              (blocarea sistemului, defectarea dispozitivului).

       datasum, nodatasum
              (implicit: activata)

              Activeaza suma de control a datelor pentru fi<?>ierele nou
              create.  Datasum implica datacow, adica modul normal de
              func<?>ionare. Toate fi<?>ierele create sub nodatasum
              mo<?>tenesc proprietatea ,,no checksums", insa nu exista un
              atribut de fi<?>ier corespondent (a se vedea chattr(1) <https://
              man7.org/linux/man-pages/man1/chattr.1.html>).

              Nota:
                 Daca nodatacow sau nodatasum sunt activate, comprimarea este
                 dezactivata.

              Se observa o u<?>oara imbunata<?>ire a performan<?>ei atunci
              cand sumele de control sunt dezactivate, deoarece blocurile de
              metadate corespunzatoare care con<?>in sumele de control nu mai
              trebuie actualizate. Costul calcularii sumelor de control pentru
              blocurile din memorie este mult mai redus decat cel al
              opera<?>iilor de In/Ie<?>, iar procesoarele moderne dispun de
              suport hardware pentru algoritmul de calcul al sumelor de
              control.

       degraded
              (implicit: dezactivata)

              Permite montari cu un numar de dispozitive mai mic decat cel
              impus de restric<?>iile profilului RAID. O montare (sau
              remontare) in mod citire-scriere poate e<?>ua atunci cand
              lipsesc prea multe dispozitive, de exemplu daca un membru al
              benzii lipse<?>te complet din RAID0.

              Incepand cu versiunea 4.14, verificarile de constrangeri au fost
              imbunata<?>ite <?>i se efectueaza la nivel de fragment, nu la
              nivel de dispozitiv. Acest lucru permite montarea in regim
              degradat a sistemelor de fi<?>iere cu profiluri RAID mixte
              pentru date <?>i metadate, chiar daca constrangerile privind
              numerele de dispozitive nu ar fi indeplinite pentru unele dintre
              profiluri.

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

              Sa presupunem ca datele sunt stocate in intregime pe sda; in
              acest caz, lipsa lui sdb nu va impiedica montarea, chiar daca,
              in mod normal, lipsa unui singur dispozitiv ar impiedica
              montarea oricarui profil single. In cazul in care unele blocuri
              de date sunt stocate pe sdb, atunci constrangerea single/data nu
              este indeplinita <?>i sistemul de fi<?>iere nu poate fi montat.

       device=<ruta-dispozitiv>
              Specifica o ruta catre un dispozitiv care va fi scanat in
              cautarea sistemului de fi<?>iere BTRFS in timpul montarii. De
              obicei, acest lucru se realizeaza automat de catre un
              administrator de dispozitive (cum ar fi udev) sau folosind
              comanda btrfs device scan (de exemplu, executata din ramdisk-ul
              ini<?>ial). In cazurile in care acest lucru nu este posibil,
              op<?>iunea de montare dispozitiv poate fi de ajutor.

              Nota:
                 Pornirea unui sistem RAID1, de exemplu, poate e<?>ua chiar
                 daca toate rutele de dispozitiv ale sistemului de fi<?>iere
                 sunt furnizate, deoarece nodurile dispozitivului actuale pot
                 sa nu fie descoperite de sistem in acel moment.

       discard, discard=sync, discard=async, nodiscard
              (implicit: asincron cand dispozitivele accepta aceasta func<?>ie
              incepand cu versiunea 6.2, suport asincron incepand cu
              versiunea: 5.6)

              Activeaza eliminarea blocurilor de fi<?>iere eliberate.  Aceasta
              op<?>iune este utila pentru dispozitivele SSD/NVMe, LUN-urile cu
              alocare redusa sau imaginile ma<?>inilor virtuale; totu<?>i,
              pentru ca aceasta sa func<?>ioneze, fiecare strat de stocare
              trebuie sa permita eliminarea.

              In modul sincron (sync sau fara valoare specificata), lipsa
              func<?>iei TRIM asincrona in coada pe dispozitivul de stocare
              poate afecta grav performan<?>a, deoarece se va incerca in
              schimb o opera<?>ie TRIM sincrona. Func<?>ia TRIM in coada
              necesita dispozitive SATA cu cipuri mai noi decat versiunea 3.1.

              Modul asincron (async) grupeaza extinderile (extents) in
              buca<?>i mai mari inainte de a le trimite catre dispozitive
              pentru opera<?>iunea TRIM. Supraincarcarea <?>i impactul asupra
              performan<?>ei ar trebui sa fie neglijabile in compara<?>ie cu
              modul anterior, iar acesta ar trebui sa fie modul preferat, daca
              este necesar.

              Daca nu este necesara eliminarea imediata a blocurilor
              eliberate, se poate folosi instrumentul fstrim pentru a elimina
              toate blocurile libere intr-un singur lot. Programarea unei
              opera<?>i TRIM intr-o perioada de activitate redusa a sistemului
              va preveni interferen<?>ele poten<?>iale cu performan<?>a altor
              opera<?>ii. De asemenea, un dispozitiv poate ignora comanda TRIM
              daca intervalul este prea mic, astfel incat executarea unei
              opera<?>ii de eliminare in lot ofera o probabilitate mai mare de
              a elimina efectiv blocurile respective.

       enospc_debug, noenospc_debug
              (implicit: dezactivata)

              Activeaza afi<?>area detaliata pentru anumite condi<?>ii ENOSPC.
              Este sigur de utilizat, dar poate fi zgomotos daca sistemul
              ajunge aproape de starea de saturare.

       fatal_errors=<ac<?>iune>
              (incepand cu: 3.4, implicit: bug)

              Ac<?>iunea de efectuat in cazul apari<?>iei unei erori fatale.

              bug    BUG() in cazul unei erori fatale, sistemul va ramane in
                     stare de blocare <?>i poate fi inca par<?>ial utilizabil,
                     dar este necesara repornirea pentru func<?>ionarea
                     completa.

              panic  panic() in cazul unei erori fatale, in func<?>ie de alte
                     configura<?>ii ale sistemului, aceasta poate fi urmata de
                     o repornire. Consulta<?>i documenta<?>ia parametrilor de
                     pornire ai nucleului, de exemplu panic, oops sau
                     crashkernel.

       flushoncommit, noflushoncommit
              (implicit: dezactivata)

              Aceasta op<?>iune for<?>eaza orice date modificate printr-o
              scriere intr-o tranzac<?>ie anterioara sa fie confirmate ca
              parte a confirmarii curente, efectiv o sincronizare completa a
              sistemului de fi<?>iere.

              Acest lucru face ca starea confirmata ,,commited" sa fie o
              vizualizare complet coerenta a sistemului de fi<?>iere din
              perspectiva aplica<?>iei (adica include toate opera<?>iile
              finalizate ale sistemului de fi<?>iere). Acest lucru se intampla
              anterior numai atunci cand era creata o iinstantanee.

              Cand este dezactivata, sistemul de fi<?>iere este consecvent,
              dar scrierile in memoria tampon pot dura mai mult de o
              tranzac<?>ie confirmata.

       fragment=<tip>
              (depinde de op<?>iunea de compilare CONFIG_BTRFS_DEBUG, incepand
              cu versiunea 4.4, implicit: dezactivata)

              Un instrument de depanare care fragmenteaza in mod inten<?>ionat
              un grup de blocuri de tipul tip specificat. Tipul poate fi data,
              metadata sau all. Aceasta op<?>iune de montare nu trebuie
              utilizata in afara mediilor de depanare <?>i nu este recunoscuta
              daca op<?>iunea de configurare a nucleului CONFIG_BTRFS_DEBUG nu
              este activata.

       nologreplay
              (implicit: dezactivata, chiar <?>i numa-pentru-citire)

              Jurnalul arborescent con<?>ine actualizarile in a<?>teptare ale
              sistemului de fi<?>iere pana la confirmarea completa. Jurnalul
              este reluat la urmatoarea montare, lucru care poate fi
              dezactivat prin aceasta op<?>iune. A se vedea <?>i treelog.
              Re<?>ine<?>i ca nologreplay este acela<?>i cu norecovery.

              Avertisment
                 In prezent, jurnalul arborescent este reluat chiar <?>i cu o
                 montare numai pentru citire! Pentru a dezactiva aceasta
                 func<?>ie, monta<?>i de asemenea cu nologreplay.

       max_inline=<octe<?>i>
              (implicit: min(2048, dimensiunea paginii) )

              Specifica cantitatea maxima de spa<?>iu care poate fi inclusa
              direct intr-o frunza a arborelui b-tree de metadate. Valoarea se
              specifica in octe<?>i, op<?>ional cu sufixul K (nu se <?>ine
              cont de majuscule/minuscule).  In practica, aceasta valoare este
              limitata de dimensiunea blocului sistemului de fi<?>iere
              (denumita sectorsize la momentul ,,mkfs",  crearii sistemului de
              fi<?>iere) <?>i de dimensiunea paginii de memorie a sistemului.
              In cazul limitei de dimensiune a sectorului, exista un spa<?>iu
              indisponibil din cauza anteturilor frunzelor b-tree. De exemplu,
              pentru o dimensiune a sectorului de 4 Kio, dimensiunea maxima a
              datelor incorporate 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 daca dimensiunile fi<?>ierelor sunt mult mai mici decat
              dimensiunea blocului, dar va reduce in schimb consumul de
              metadate.

              Nota:
                 Valoarea implicita a fost modificata la 2048 in nucleul 4.6.

       metadata_ratio=<valoare>
              (implicit: 0, logica interna)

              Specifica faptul ca trebuie alocat 1 bloc de metadate dupa
              fiecare valoare blocuri de date. Comportamentul implicit depinde
              de logica interna; se incearca men<?>inerea unui anumit procent
              de spa<?>iu neutilizat pentru metadate, dar acest lucru nu este
              intotdeauna posibil daca nu exista suficient spa<?>iu disponibil
              pentru alocarea blocurilor. Op<?>iunea poate fi utila pentru a
              suprascrie logica interna in favoarea alocarii metadatelor daca
              se preconizeaza ca volumul de lucru va implica un numar mare de
              metadate (instantanee, legaturi de referin<?>a, atribute de
              fi<?>iere, fi<?>iere incorporate).

       norecovery
              (incepand cu: 4.5, implicit: dezactivata)

              Nu incearca nicio recuperare de date in momentul montarii.
              Aceasta va dezactiva logreplay <?>i va evita alte opera<?>ii de
              scriere. Re<?>ine<?>i ca aceasta op<?>iune este identica cu
              nologreplay.

              Nota:
                 Op<?>iunea opusa, recovery, avea ini<?>ial o semnifica<?>ie
                 diferita, dar a fost modificata pentru a asigura coeren<?>a
                 cu alte sisteme de fi<?>iere, in care norecovery este
                 utilizata pentru a omite redarea jurnalului. BTRFS procedeaza
                 la fel <?>i, in general, va incerca sa evite orice opera<?>ii
                 de scriere.

       rescan_uuid_tree
              (incepand cu: 3.12, implicit: dezactivata)

              For<?>eaza verificarea <?>i procedura de reconstruire a
              arborelui UUID. In mod normal, acest lucru nu ar trebui sa fie
              necesar. Alternativ, arborele poate fi <?>ters din spa<?>iul
              utilizatorului prin comanda btrfs rescue clear-uuid-tree <#
              man-rescue-clear-uuid-tree>, iar apoi va fi reconstruit automat
              in nucleu (in acest caz, op<?>iunea de montare nu este
              necesara).

       rescue (incepand cu: 5.9)

              Modurile care permit montarea cu structuri ale sistemului de
              fi<?>iere deteriorate impun ca sistemul de fi<?>iere sa fie
              montat in mod ,,doar-citire" <?>i nu permit remontarea in mod
              ,,citire-scriere".  Acest lucru are rolul de a oferi o
              gestionare unificata <?>i mai detaliata a erorilor care
              afecteaza func<?>ionarea sistemului de fi<?>iere.

              o usebackuproot (incepand cu: 5.9)

                Incearca sa utilizeze sloturile radacina de copie de rezerva
                din blocul super. Inlocuie<?>te op<?>iunea independenta
                usebackuproot

              o nologreplay (incepand cu: 5.9)

                Nu reia niciun jurnal murdar. Inlocuie<?>te op<?>iunea
                independenta nologreplay.

              o ignorebadroots, ibadroots (incepand cu: 5.11)

                Ignora radacinile arborescente deteriorate, imbunata<?>e<?>te
                considerabil <?>ansele de recuperare a datelor.

              o ignoredatacsums, idatacsums (incepand cu: 5.11)

                Ignora verificarea sumei de control a datelor.

              o ignoremetacsums, imetacsums (incepand cu: 6.12)

                Ignora verificarea sumelor de control ale metadatelor, utila
                pentru conversia sumelor de control intrerupta.

              o all (incepand cu: 5.9)

                Activeaza toate op<?>iunile de recuperare acceptate.

       skip_balance
              (incepand cu: 3.3, implicit: dezactivata)

              Omite reluarea automata a unei opera<?>ii de echilibrare
              intrerupte. Opera<?>ia poate fi reluata ulterior cu comanda
              btrfs balance resume, sau starea de pauza poate fi eliminata cu
              comanda btrfs balance cancel. Comportamentul implicit este
              reluarea unei opera<?>ii de echilibrare intrerupte imediat dupa
              montarea sistemului de fi<?>iere.

       space_cache, space_cache=<versiune>, nospace_cache
              (nospace_cache incepand cu: 3.2, space_cache=v1 <?>i
              space_cache=v2 incepand cu: 4.5, implicit: space_cache=v2)

              Op<?>iuni pentru gestionarea cache-ului de spa<?>iu liber.
              Cache-ul de spa<?>iu liber imbunata<?>e<?>te considerabil
              performan<?>a la citirea in memorie a spa<?>iului liber din
              grupurile de blocuri. Cu toate acestea, gestionarea cache-ului
              de spa<?>iu consuma anumite resurse, inclusiv o cantitate redusa
              de spa<?>iu pe disc.

              Exista doua variante de implementare a cache-ului de spa<?>iu
              liber. Varianta ini<?>iala, denumita v1, era considerata o
              op<?>iune implicita sigura, dar a fost inlocuita de v2. Cache-ul
              de spa<?>iu v1 poate fi dezactivat la montare folosind
              op<?>iunea nospace_cache, fara a fi necesara <?>tergerea
              con<?>inutului.

              In 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 adauga un nou arbore b-tree numit
              ,,arbore de spa<?>iu liber", rezolva aceasta problema. Odata
              activat, cache-ul de spa<?>iu v2 va fi utilizat intotdeauna <?>i
              nu poate fi dezactivat decat daca este golit. Utiliza<?>i
              clear_cache,space_cache=v1 sau clear_cache,nospace_cache pentru
              a face acest lucru. Daca v2 este activata, cache-ul de spa<?>iu
              v1 va fi <?>ters (la prima montare), iar nucleele fara suport v2
              vor putea monta sistemul de fi<?>iere doar in 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 incepand cu
              versiunea v4.19.

              Daca nu este specificata in mod explicit o versiune, va fi
              aleasa implementarea implicita, care este v2.

       ssd, ssd_spread, nossd, nossd_spread
              (implicit: SSD detectat automat)

              Op<?>iuni pentru controlul schemelor de alocare a SSD-urilor. In
              mod implicit, BTRFS va activa sau dezactiva optimizarile pentru
              SSD-uri in func<?>ie de tipul dispozitivului (rotativ sau
              nerotativ). Acest lucru este determinat de con<?>inutul
              fi<?>ierului /sys/block/DEV/queue/rotational. Daca valoarea este
              0, op<?>iunea ssd este activata. Op<?>iunea nossd va dezactiva
              detectarea automata.

              Optimizarile utilizeaza absen<?>a penalizarii de cautare care
              este inerenta pentru dispozitivele rotative. Blocurile pot fi de
              obicei scrise mai rapid <?>i nu sunt transferate catre fire de
              execu<?>ie separate.

              Nota:
                 Incepand cu versiunea 4.14, optimizarile 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 sa imbunata<?>easca rezisten<?>a la uzura
                 printr-o aliniere mai buna a blocurilor. Acest lucru nu mai
                 este valabil in cazul dispozitivelor SSD moderne, iar
                 optimizarea nu mai aducea niciun beneficiu real. In plus,
                 aceasta ducea la o fragmentare crescuta. Ajustarea dispunerii
                 a fost pastrata intacta pentru op<?>iunea ssd_spread.

              Op<?>iunea de montare ssd_spread incearca sa aloce spa<?>iu
              neutilizat in blocuri mai mari <?>i aliniate, putand oferi
              performan<?>e mai bune pe SSD-urile de gama inferioara.
              ssd_spread include implicit ssd, activand astfel <?>i toate
              celelalte algoritme pentru SSD-uri. Op<?>iunea nossd va
              dezactiva toate op<?>iunile pentru SSD-uri, in timp ce
              nossd_spread dezactiveaza doar ssd_spread.

       subvol=<ruta>
              Monteaza sub-volumul din ruta in loc de subvolumul de nivel
              superior. ruta este intotdeauna tratata ca fiind relativa la
              subvolumul de nivel superior. Aceasta op<?>iune de montare
              prevaleaza asupra setului implicit de subvolum pentru sistemul
              de fi<?>iere dat.

       subvolid=<id-_sub-vol>
              Monteaza subvolumul specificat printr-un numar id-_sub-vol, in
              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. Aceasta op<?>iune de
              montare inlocuie<?>te setul de sub-volume implicit pentru
              sistemul de fi<?>iere respectiv.

              Nota:
                 Daca sunt specificate atat subvolid cat <?>i subvol, acestea
                 trebuie sa indice acela<?>i subvolum, altfel montarea va
                 e<?>ua.

       thread_pool=<numar>
              (implicit: min(NR.CPU-uri + 2, 8) )

              Numarul de fire de execu<?>ie care trebuie pornite. NRCPUS
              reprezinta numarul de procesoare active detectate in momentul
              montarii. Un numar mic duce la un paralelism redus in procesarea
              datelor <?>i a metadatelor, iar un numar mare ar putea duce la o
              scadere a performan<?>ei din cauza intensificarii conflictelor
              de blocare, a planificarii proceselor, a ,,bouncing-ului
              (respingerii)" liniilor de cache sau a transferurilor
              costisitoare de date intre memoriile locale ale procesoarelor.

       treelog, notreelog
              (implicit: activata)

              Activeaza jurnalul arborescent utilizat pentru opera<?>iile de
              scriere fsync <?>i O_SYNC. Jurnalul arborescent stocheaza
              modificarile fara a fi necesara o sincronizare completa a
              sistemului de fi<?>iere. Opera<?>iile din jurnal sunt salvate la
              sincronizare <?>i la confirmarea tranzac<?>iei. Daca sistemul se
              blocheaza intre doua astfel de sincronizari, opera<?>iile din
              jurnalul arborescent aflate in a<?>teptare sunt reluate in
              timpul montarii.

              Avertisment
                 In prezent, jurnalul arborescent este redat chiar <?>i cu o
                 montare numai pentru citire! Pentru a dezactiva aceasta
                 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 daca jurnalul nu este
              reluat.

       usebackuproot
              (incepand cu: 4.6, implicit: dezactivata)

              Activeaza incercarile de autorecuperare in cazul in care se
              gase<?>te o radacina gre<?>ita a arborelui in momentul montarii.
              In prezent, aceasta scaneaza o lista de rezerva a mai multor
              radacini anterioare ale arborelui <?>i incearca sa utilizeze
              prima care poate fi citita. Acest lucru poate fi utilizat <?>i
              in cazul montarilor numai-pentru-citire.

              Nota:
                 Aceasta op<?>iune a inlocuit recovery, care a fost
                 depreciata.

       user_subvol_rm_allowed
              (implicit: dezactivata)

              Permite ca subvolumele sa fie <?>terse de catre proprietarul
              lor. In caz contrar, numai utilizatorul root poate face acest
              lucru.

              Nota:
                 In trecut, orice utilizator putea crea o instantanee chiar
                 daca nu era proprietarul sub-volumului sursa; din acest
                 motiv, <?>tergerea sub-volumului a fost restric<?>ionata.
                 Crearea sub-volumului a fost restric<?>ionata, dar aceasta
                 op<?>iune de montare este inca necesara. Aceasta reprezinta o
                 problema de utilizare. Incepand cu versiunea 4.18, apelul de
                 sistem rmdir(2) <https://man7.org/linux/man-pages/man2/rmdir
                 .2.html> poate <?>terge un sub-volum gol la fel ca un
                 director obi<?>nuit. Daca acest lucru este posibil poate fi
                 detectat in timpul rularii, consulta<?>i caracteristica
                 rmdir_subvol din sec<?>iunea CARACTERISTICI ALE SISTEMULUI DE
                 FI<?>IERE.

   OP<?>IUNI DE MONTARE DEPRECIATE
       Listeaza op<?>iunile de montare care au fost eliminate, pastrate pentru
       compatibilitate cu versiunile anterioare.

       recovery
              (incepand cu: 3.2, implicit: dezactivata, depreciata incepand
              cu: 4.5)

              Nota:
                 Aceasta op<?>iune a fost inlocuita de usebackuproot <?>i nu
                 trebuie utilizata, dar va func<?>iona pe nucleele 4.5+.

       inode_cache, noinode_cache
              (eliminata in: 5.11, incepand cu: 3.0, implicit: dezactivata)

              Nota:
                 Func<?>ionalitatea a fost eliminata in versiunea 5.11, orice
                 date vechi create prin utilizarea anterioara a op<?>iunii
                 inode_cache pot fi eliminate prin btrfs rescue
                 clear-ino-cache <#man-rescue-clear-ino-cache>.

       check_int, check_int_data, check_int_print_mask=<valoare>
              (eliminata in: 6.7, incepand cu: 3.0, implicit: dezactivata)

              Aceste op<?>iuni de depanare controleaza comportamentul
              modulului de verificare a integrita<?>ii (este necesara
              op<?>iunea de configurare BTRFS_FS_CHECK_INTEGRITY). Scopul
              principal este de a verifica daca toate blocurile dintr-o
              anumita perioada de tranzac<?>ionare sunt legate in mod
              corespunzator.

              check_int activeaza modulul de verificare a integrita<?>ii, care
              examineaza toate cererile de scriere in bloc pentru a asigura
              coeren<?>a pe disc, cu un cost mare de memorie <?>i CPU.

              check_int_data include date de extindere (extent) in
              verificarile de integritate <?>i implica op<?>iunea check_int.

              check_int_print_mask accepta o masca de bi<?>i cu valori
              BTRFSIC_PRINT_MASK_*, a<?>a cum sunt definite in
              fs/btrfs/check-integrity.c, pentru a controla comportamentul
              modulului de verificare a integrita<?>ii.

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

   NOTE PRIVIND OP<?>IUNILE DE MONTARE GENERICE
       Unele dintre op<?>iunile generale de montare din mount(8) <https://man7
       .org/linux/man-pages/man8/mount.8.html> care afecteaza BTRFS <?>i
       merita men<?>ionate.

       context
              Contextul se refera la contextele SELinux <?>i la defini<?>iile
              politicilor transmise ca op<?>iuni de montare. Acest lucru
              func<?>ioneaza corect incepand cu versiunea v6.8 (deoarece
              analizatorul op<?>iunilor de montare din BTRFS a fost adaptat la
              noul API care in<?>elege <?>i op<?>iunile).

       noatime
              In condi<?>ii de incarcare intensa de citire, specificarea
              op<?>iunii noatime imbunata<?>e<?>te semnificativ performan<?>a,
              deoarece nu este necesara scrierea de noi informa<?>ii privind
              timpul de acces. Fara aceasta op<?>iune, valoarea implicita este
              relatime, care reduce doar numarul de actualizari atime ale
              nodurilor-i in compara<?>ie cu tradi<?>ionalul strictatime. Cel
              mai rau scenariu pentru actualizarile atime sub relatime apare
              atunci cand sunt citite multe fi<?>iere al caror atime este mai
              vechi de 24 de ore <?>i care au fost recent salvate in
              instantanee. In acest caz, atime este actualizat <?>i COW are
              loc -- pentru fiecare fi<?>ier -- in bloc. A se vedea <?>i
              <https://lwn.net/Articles/499293/> - Atime and btrfs: a bad
              combination? (LWN, 2012-05-31).

              Re<?>ine<?>i ca noatime poate afecta aplica<?>iile care se
              bazeaza pe timpul de func<?>ionare atime, cum ar fi venerabilul
              Mutt (cu excep<?>ia cazului in care utiliza<?>i casu<?>ele
              po<?>tale maildir).

CARACTERISTICI ALE SISTEMULUI DE FI<?>IERE
       Setul de baza de caracteristici ale sistemului de fi<?>iere se extinde
       in timp. Compatibilitatea cu versiunile anterioare este men<?>inuta,
       iar caracteristicile sunt op<?>ionale <?>i trebuie solicitate explicit,
       astfel incat utilizarea accidentala sa nu creeze incompatibilita<?>i.

       Exista mai multe clase <?>i instrumentele corespunzatoare pentru
       gestionarea func<?>iilor:

       at mkfs time only
              Acest lucru este valabil in special pentru structurile de baza,
              cum ar fi dimensiunea nodului b-tree sau algoritmul de
              verificare a sumelor de control. Pentru mai multe detalii,
              consulta<?>i mkfs.btrfs(8) <>.

       dupa mkfs, pe un sistem de fi<?>iere nemontat
              Func<?>ionalita<?>i care pot optimiza structurile interne sau
              adauga structuri noi pentru a sus<?>ine func<?>ionalita<?>i noi;
              consulta<?>i btrfstune(8) <>. Comanda btrfs inspect-internal
              dump-super /dev/sdx va genera extragerea <?>i afi<?>area
              super-blocului; pute<?>i corela valoarea lui incompat_flags cu
              func<?>ionalita<?>ile enumerate mai jos

       dupa mkfs, pe un sistem de fi<?>iere montat
              Caracteristicile unui sistem de fi<?>iere (cu un anumit UUID)
              sunt enumerate in /sys/fs/btrfs/UUID/features/, cate un fi<?>ier
              pentru fiecare caracteristica. Starea este stocata in interiorul
              fi<?>ierului. Valoarea 1 indica faptul ca caracteristica este
              activata <?>i func<?>ionala, in timp ce 0 inseamna ca
              caracteristica a fost activata la montare, dar a fost
              dezactivata ulterior.

              In directorul /sys/fs/btrfs/features/ se poate afla daca o
              anumita caracteristica poate fi activata pe un sistem de
              fi<?>iere montat, un fi<?>ier pentru fiecare caracteristica.
              Valoarea 1 inseamna ca func<?>ia poate fi activata.

       Lista caracteristicilor (a se vedea <?>i mkfs.btrfs(8) <> sec<?>iunea
       CARACTERISTICI ALE SISTEMULUI DE FI<?>IERE <#
       man-mkfs-filesystem-features>):

       big_metadata
              (incepand cu: 3.4)

              sistemul de fi<?>iere utilizeaza nodesize pentru blocurile de
              metadate, care pot fi mai mari decat dimensiunea paginii

       block_group_tree
              (incepand 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
              (incepand cu: 2.6.38)

              comprimarea lzo a fost utilizata pe sistemul de fi<?>iere, fie
              ca op<?>iune de montare, fie prin btrfs filesystem defrag.

       compress_zstd
              (incepand cu: 4.14)

              comprimarea zstd a fost utilizata pe sistemul de fi<?>iere, fie
              ca op<?>iune de montare, fie prin btrfs filesystem defrag.

       default_subvol
              (incepand cu: 2.6.34)

              subvolumul implicit a fost definit pe sistemul de fi<?>iere

       extended_iref
              (incepand cu: 3.7)

              a fost marita limita legaturilor dure pe fi<?>ier intr-un
              director la 65536, nucleele mai vechi acceptau un numar variabil
              de legaturi dure in func<?>ie de suma tuturor dimensiunilor
              numelor de fi<?>iere care pot fi stocate intr-un bloc de
              metadate

       free_space_tree
              (incepand cu: 4.5)

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

       metadata_uuid
              (incepand cu: 5.0)

              UUID-ul principal al sistemului de fi<?>iere este metadata_uuid,
              care stocheaza noul UUID numai in superbloc, in timp ce toate
              blocurile de metadate au inca UUID-ul stabilit la momentul mkfs,
              consulta<?>i btrfstune(8) <> pentru mai multe detalii

       mixed_backref
              (incepand cu: 2.6.31)

              ultima modificare majora a formatului discului, referin<?>e
              inversate imbunata<?>ite, acum implicite

       mixed_groups
              (incepand cu: 2.6.37)

              grupuri de blocuri mixte de date <?>i metadate, adica datele
              <?>i metadatele nu sunt separate <?>i ocupa acelea<?>i grupuri
              de blocuri; acest mod este potrivit pentru volume mici, deoarece
              nu exista restric<?>ii privind modul in care trebuie utilizat
              spa<?>iul ramas (spre deosebire de modul ,,split", in care
              spa<?>iul gol al metadatelor nu poate fi utilizat pentru date
              <?>i viceversa)

              pe de alta parte, aspectul final este destul de imprevizibil
              <?>i posibil foarte fragmentat, ceea ce inseamna performan<?>e
              mai slabe

       no_holes
              (incepand cu: 3.14)

              reprezentare imbunata<?>ita a extensiilor fi<?>ierelor in care
              golurile nu sunt stocate in mod explicit ca extensie,
              economise<?>te cateva procente din metadate daca se utilizeaza
              fi<?>iere disperse

       raid1c34
              (incepand cu: 5.5)

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

       raid_stripe_tree
              (incepand cu: 6.7)

              un arbore separat pentru urmarirea extensiilor fi<?>ierelor pe
              profilurile RAID

       RAID56 (incepand cu: 3.9)

              sistemul de fi<?>iere con<?>ine sau a con<?>inut un profil
              RAID56 de grupuri de blocuri

       rmdir_subvol
              (incepand cu: 4.18)

              indica faptul ca apelul de sistem rmdir(2) %<https://man7.org/
              linux/man-pages/man2/rmdir.2.html> poate <?>terge un subvolum
              gol la fel ca un director obi<?>nuit. Re<?>ine<?>i ca aceasta
              caracteristica depinde numai de versiunea nucleului.

       skinny_metadata
              (incepand cu: 3.10)

              metadate de dimensiuni reduse pentru referin<?>ele de
              extindere(extent), economisesc cateva procente din metadate

       send_stream_version
              (incepand cu: 5.10)

              numarul celei mai recente versiuni acceptate pentru fluxul de
              trimitere

       simple_quota
              (incepand cu: 6.7)

              contabilizarea simplificata a cotelor

       supported_checksums
              (incepand cu: 5.5)

              lista algoritmilor de suma de control accepta<?>i de modulul
              nucleului, modulele respective sau modulele integrate care
              implementeaza algoritmii trebuie sa fie prezente pentru a monta
              sistemul de fi<?>iere, a se vedea sec<?>iunea ALGORITMI DE SUMA
              DE CONTROL.

       supported_sectorsizes
              (incepand cu: 5.13)

              listeaza valorile acceptate ca dimensiuni ale sectoarelor
              (mkfs.btrfs --sectorsize) de catre nucleul in execu<?>ie

       supported_rescue_options
              (incepand cu: 5.11)

              listeaza valorile pentru op<?>iunea de montare rescue care sunt
              acceptate de nucleul in execu<?>ie, a se vedea btrfs(5) <>

       zoned  (incepand cu Linux 5.12)

              modul ,,zoned" este prietenos cu alocarea/scrierea pentru
              dispozitivele impar<?>ite in zone, gestionate de gazda,
              spa<?>iul de alocare este impar<?>it in zone de dimensiuni fixe
              care trebuie actualizate secven<?>ial, a se vedea sec<?>iunea
              MODUL ,,ZONED"

SUPORT PENTRU FI<?>IERUL DE INTERSCHIMB (SWAP)
       Un fi<?>ier swap, atunci cand este activ, reprezinta o zona de swap
       stocata intr-un fi<?>ier.  Este acceptat incepand cu versiunea 5.0 a
       nucleului.  Folosi<?>i swapon(8) <https://man7.org/linux/man-pages/
       man8/swapon.8.html> pentru a-l activa, pana atunci (respectiv din nou
       dupa dezactivarea acestuia cu swapoff (8) <https://man7.org/linux/
       man-pages/man8/swapoff.8.html>) acesta este doar un fi<?>ier normal (cu
       NODATACOW activat) pentru care restric<?>iile speciale pentru
       fi<?>ierele swap active nu se aplica.

       Exista cateva limitari ale implementarii in BTRFS <?>i subsistemul swap
       Linux:

       o filesystem - trebuie sa fie un singur dispozitiv

       o trebuie sa aiba doar un singur profil de date

       o subvolume - nu se poate crea o instantanee a acestuia daca con<?>ine
         fi<?>iere swap active

       o swapfile - trebuie sa fie prealocat (adica fara goluri)

       o swapfile - trebuie sa fie NODATACOW (adica, de asemenea, NODATASUM,
         fara comprimare)

       Limitarile decurg in special din arhitectura bazata pe COW <?>i din
       stratul de cartografiere a blocurilor, care permite func<?>ionalita<?>i
       avansate precum realocarea <?>i sistemele de fi<?>iere pe mai multe
       dispozitive. Cu toate acestea, subsistemul swap se bazeaza pe o
       cartografiere mai simpla <?>i nu accepta modificari in fundal ale
       loca<?>iei blocurilor de fi<?>iere odata ce acestea au fost alocate
       spa<?>iului swap. Constrangerile men<?>ionate mai sus (un singur
       dispozitiv <?>i un singur profil) sunt legate de fi<?>ierul swap in
       sine, adica de extinderi(extents) <?>i de amplasarea acestora. Este
       posibil sa se creeze un fi<?>ier swap pe un sistem de fi<?>iere cu mai
       multe dispozitive, atata timp cat extinderile se afla 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, urmatoarele opera<?>iuni asupra intregului
       sistem de fi<?>iere vor omite extensiile (extents) fi<?>ierului swap
       sau pot e<?>ua:

       o balance - grupurile de blocuri cu extinderi (extents) ale oricaror
         fi<?>iere swap active sunt omise <?>i raportate, restul vor fi
         procesate in mod normal

       o resize grow - neafectat

       o resize shrink - func<?>ioneaza atata timp cat extensiile (extents)
         oricaror fi<?>iere swap active se afla in afara intervalului redus

       o device add - daca noile dispozitive nu interfereaza cu niciun
         fi<?>ier swap deja activ, aceasta opera<?>ie va func<?>iona, insa nu
         se va putea activa niciun fi<?>ier swap nou dupa aceea

       o device delete - daca dispozitivul a fost adaugat conform
         instruc<?>iunilor de mai sus, acesta poate fi <?>i <?>ters

       o device replace - idem

       Cand nu exista fi<?>iere swap active <?>i se executa o opera<?>ie
       exclusiva asupra intregului sistem de fi<?>iere (de exemplu,
       echilibrare, <?>tergere dispozitiv, mic<?>orare), fi<?>ierele swap nu
       pot fi activate temporar. Opera<?>ia trebuie sa se incheie mai intai.

       Pentru a crea <?>i activa un fi<?>ier swap, executa<?>i urmatoarele
       comenzi:

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

       Incepand cu versiunea 6.1, este posibil sa crea<?>i fi<?>ierul swap cu
       o singura comanda (cu excep<?>ia activarii):

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

       Re<?>ine<?>i ca UUID-ul returnat de instrumentul mkswap identifica
       ,,sistemul de fi<?>iere" swap <?>i, deoarece este stocat intr-un
       fi<?>ier, acesta nu este, in general, vizibil <?>i nu poate fi utilizat
       ca identificator, spre deosebire de cazul in care s-ar afla pe un
       dispozitiv de blocuri.

       Odata activat, fi<?>ierul va aparea in /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 unica sau, odata
       creat corespunzator, poate fi activat la fiecare pornire a sistemului
       prin comanda <<swapon -a>> (de obicei lansata de gestionarul de
       servicii). Adauga<?>i urmatoarea intrare in /etc/fstab, presupunand ca
       sistemul de fi<?>iere care furnizeaza /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 inainte, sub-volumul care con<?>ine fi<?>ierul swap activ nu
       poate fi inclus intr-o instantanee pana cand fi<?>ierul swap nu este
       dezactivat din nou cu comanda swapoff. In acest moment, fi<?>ierul swap
       devine un fi<?>ier obi<?>nuit, iar sub-volumul poate fi inclus din nou
       intr-o instantanee, de<?>i acest lucru ar impiedica o noua activare a
       oricarui fi<?>ier swap care a fost inclus intr-o instantanee. Se pot
       crea <?>i activa fi<?>iere swap noi (care nu au fost incluse intr-o
       instantanee).

       In caz contrar, un fi<?>ier swap inactiv nu afecteaza subvolumul care
       il con<?>ine. Activarea creeaza un statut temporar in memorie <?>i
       impiedica unele opera<?>ii cu fi<?>iere, dar nu este stocata permanent.

HIBERNARE
       Un fi<?>ier de swap poate fi utilizat pentru hibernare, dar acest lucru
       nu este chiar atat de simplu. Inainte de hibernare, trebuie sa se scrie
       o pozi<?>ie de reluare in fi<?>ierul ,,/sys/power/resume_offset" sau
       trebuie definit parametrul de linie de comanda al nucleului
       resume_offset.

       Valoarea este decalajul fizic pe dispozitiv. Re<?>ine<?>i ca aceasta nu
       este aceea<?>i valoare cu filefrag afi<?>ata ca decalaj fizic!

       Sistemul de fi<?>iere Btrfs utilizeaza o coresponden<?>a intre adresele
       logice <?>i cele fizice, insa, in acest caz, adresa fizica poate fi
       asociata in continuare cu una sau mai multe adrese de bloc fizic
       specifice dispozitivului. Decalajul fizic specific dispozitivului este
       cel care se preteaza a fi utilizat ca pozi<?>ia de reluare.

       Incepand cu versiunea 6.1, exista o comanda btrfs inspect-internal
       map-swapfile <#man-inspect-map-swapfile> care afi<?>eaza decalajul
       fizic al dispozitivului <?>i valoarea ajustata pentru
       /sys/power/resume_offset.  Re<?>ine<?>i ca valoarea este impar<?>ita la
       dimensiunea paginii, adica nu reprezinta decalajul in sine.

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

       Pentru scripturi <?>i comoditate, op<?>iunea -r va afi<?>a doar
       decalajul:

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

       Comanda map-swapfile verifica, de asemenea, toate cerin<?>ele, adica
       lipsa golurilor, dispozitiv unic etc.

SOLU<?>IONAREA PROBLEMELOR
       Daca activarea fi<?>ierului swap e<?>ueaza, verifica<?>i daca 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.

       In mod special, instrumentul swapon se inchide cu un mesaj care nu
       precizeaza ce anume a e<?>uat:

          # swapon /ruta-la/swapfile
          swapon: /ruta-la/swapfile: swapon a e<?>uat: argument nevalid

       Motivul specific va fi probabil inregistrat in jurnalul de sistem de
       catre modulul btrfs:

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

ALGORITMI DE SUMA DE CONTROL
       Datele <?>i metadatele sunt verificate prin suma de control in mod
       implicit. Suma de control este calculata inainte de scriere <?>i
       verificata dupa citirea blocurilor de pe dispozitive. Intregul bloc de
       metadate are o suma de control integrata, stocata in antetul nodului
       arborelui b-tree. Fiecare bloc de date are o suma de control separata,
       stocata in arborele de sume de control.

       Nota:
          Deoarece suma de control a datelor este calculata chiar inainte de
          trimiterea catre dispozitivul bloc, btrfs are o cerin<?>a stricta ca
          blocul de date corespunzator sa nu fie modificat pana la finalizarea
          opera<?>iei de scriere.

          Aceasta cerin<?>a este indeplinita in cazul unei scrieri cu memorie
          tampon, deoarece Btrfs de<?>ine controlul deplin asupra cache-ului
          de pagini; insa o scriere directa (O_DIRECT) ocole<?>te cache-ul de
          pagini, iar Btrfs nu poate controla memoria tampon de In/Ie<?>
          directa (deoarece aceasta se poate afla in memoria spa<?>iului de
          utilizator)  Astfel, este posibil ca un program din spa<?>iul
          utilizatorului sa modifice memoria tampon de scriere directa inainte
          ca aceasta sa fie complet rescrisa, iar acest lucru poate duce la o
          neconcordan<?>a a sumei de control a datelor.

          Pentru a evita acest lucru, nucleul incepand cu versiunea 6.14 va
          for<?>a o opera<?>ie de scriere directa sa treaca la modul cu
          memorie tampon, in cazul in care nodul-i necesita o suma de control
          a datelor. Acest lucru va implica o u<?>oara scadere a
          performan<?>ei. Daca ave<?>i nevoie de opera<?>ii de scriere directa
          cu zero copii, activa<?>i fanionul NODATASUM pentru nodul-i <?>i
          asigura<?>i-va ca memoria tampon pentru opera<?>iile de In/Ie<?>
          directe este aliniata complet la dimensiunea blocului.

       Sunt accepta<?>i mai mul<?>i algoritmi de suma de control. Algoritmul
       implicit <?>i compatibil cu versiunile anterioare este crc32c. Incepand
       cu versiunea 5.5 a nucleului, exista inca trei algoritmi cu
       caracteristici diferite <?>i compromisuri in ceea ce prive<?>te viteza
       <?>i rezisten<?>a. Lista de mai jos va poate ajuta sa decide<?>i pe
       care dintre ace<?>tia sa il alege<?>i.

       CRC32C (rezumat de 32 bi<?>i)
              Implicit, cea mai buna compatibilitate cu versiunile anterioare.
              Foarte rapid, procesoarele moderne au suport la nivel de
              instruc<?>iuni, nu este rezistent la coliziuni, dar are totu<?>i
              capacita<?>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 utilizeaza pipeline de
              instruc<?>iuni, rezisten<?>a buna la coliziuni <?>i detectare a
              erorilor.

       SHA256 (rezumat de 256 bi<?>i)
              Algoritm de sum[ de control cu putere criptografica. Relativ
              lent, dar cu posibilitate de accelerare a instruc<?>iunilor CPU
              sau carduri hardware specializate. Certificat FIPS <?>i utilizat
              pe scara larga.

       BLAKE2b (rezumat de 256 bi<?>i)
              Algoritm de suma de control cu putere criptografica. Relativ
              rapid, cu posibilitate de accelerare prin procesor folosind
              extensii SIMD. Nu este standardizat, dar se bazeaza pe BLAKE,
              care a fost finalist la SHA3 <?>i este utilizat pe scara larga.
              Algoritmul folosit este BLAKE2b-256, optimizat pentru platforme
              pe 64 de bi<?>i.

       Valoarea dimensiune rezumat influen<?>eaza dimensiunea totala a sumelor
       de control ale blocurilor de date stocate in sistemul de fi<?>iere.
       Blocurile de metadate au o dimensiune fixa de pana la 256 de bi<?>i (32
       de octe<?>i), astfel incat nu se inregistreaza nicio cre<?>tere.
       Fiecare bloc de date are o suma de control stocata separat, cu un volum
       suplimentar reprezentat de frunzele arborelui b-tree.

       Performan<?>a relativa aproximativa a algoritmilor, masurata in
       compara<?>ie cu CRC32C utilizand implementari 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<?>a        |
               |        |              |        | implementare       |
               +--------+--------------+--------+--------------------+
               |SHA256  | 7600         | 16     | libgcrypt          |
               +--------+--------------+--------+--------------------+
               |SHA256  | 8500         | 18     | openssl            |
               +--------+--------------+--------+--------------------+
               |SHA256  | 8700         | 18     | botan              |
               +--------+--------------+--------+--------------------+
               |SHA256  | 32000        | 68     | incorporat,        |
               |        |              |        | instruc<?>iune CPU |
               +--------+--------------+--------+--------------------+
               |SHA256  | 37000        | 78     | libsodium          |
               +--------+--------------+--------+--------------------+
               |SHA256  | 78000        | 166    | incorporat,        |
               |        |              |        | referin<?>a        |
               |        |              |        | implementare       |
               +--------+--------------+--------+--------------------+
               |BLAKE2b | 10000        | 21     | incorporat/AVX2    |
               +--------+--------------+--------+--------------------+
               |BLAKE2b | 10900        | 23     | libgcrypt          |
               +--------+--------------+--------+--------------------+
               |BLAKE2b | 13500        | 29     | incorporat/SSE41   |
               +--------+--------------+--------+--------------------+
               |BLAKE2b | 13700        | 29     | libsodium          |
               +--------+--------------+--------+--------------------+
               |BLAKE2b | 14100        | 30     | openssl            |
               +--------+--------------+--------+--------------------+
               |BLAKE2b | 14500        | 31     | kcapi              |
               +--------+--------------+--------+--------------------+
               |BLAKE2b | 14500        | 34     | incorporat,        |
               |        |              |        | referin<?>a        |
               |        |              |        | implementare       |
               +--------+--------------+--------+--------------------+
       Multe nuclee sunt configurate cu SHA256 integrat, nu sub forma de
       modul. Pana la versiunea v6.15 a nucleului, versiunile accelerate sunt
       totu<?>i furnizate de module <?>i trebuie incarcate in mod explicit
       (modprobe sha256) inainte de montarea sistemului de fi<?>iere pentru a
       le putea utiliza. Pute<?>i verifica in /sys/fs/btrfs/FSID/checksum care
       dintre ele este utilizat. Daca vede<?>i sha256-generic, atunci ar fi
       bine sa demonta<?>i <?>i sa monta<?>i din nou sistemul de fi<?>iere. Nu
       este posibila modificarea acestui lucru pe un sistem de fi<?>iere
       montat.

       Incepand cu nucleul v6.16, implementarea accelerata este utilizata
       intotdeauna, daca este disponibila.

       Verifica<?>i fi<?>ierul /proc/crypto. Cand implementarea este
       integrata, ve<?>i gasi:

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

       In timp ce pentru implementarea accelerata este, de exemplu:

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

COMPRIMARE
       Btrfs supports transparent file compression. There are three algorithms
       available: ZLIB, LZO and ZSTD (since v4.14), with various levels.  The
       compression happens on the level of file extents and the algorithm is
       selected by file property, mount option or by a defrag command.  You
       can have a single btrfs mount point that has some files that are
       uncompressed, some that are compressed with LZO, some with ZLIB, for
       instance (though you may not want it that way, it is supported).

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

       Algoritmii pot fi caracteriza<?>i dupa cum urmeaza in ceea ce
       prive<?>te compromisurile dintre viteza <?>i raport:

       ZLIB

              o mai lent, raport de comprimare mai mare

              o niveluri: de la 1 la 9, atribuite direct, nivelul implicit
                este 3

              o compatibilitate buna cu versiunile anterioare

       LZO

              o comprimare <?>i decomprimare mai rapide decat ZLIB, raport de
                comprimare mai slab, conceput pentru a fi rapid

              o fara nivele

              o compatibilitate buna cu versiunile anterioare

       ZSTD

              o comprimare comparabila cu ZLIB, cu viteze mai mari de
                comprimare/decomprimare <?>i raport diferit

              o niveluri: -15..15, atribuite direct, valoarea implicita este 3

              o suport, incepand cu: 4.14

              o niveluri 1..15 acceptat incepand cu versiunea 5.1

              o niveluri -15..-1 acceptat incepand cu versiunea 6.15

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

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

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

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

          $ btrfs filesystem defrag -czstd fi<?>ier

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

       Configurarile persistente pentru fiecare fi<?>ier in parte pot fi
       configurate in doua moduri:

          $ chattr +c fi<?>ier
          $ btrfs property set fi<?>ier compression zstd

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

NIVELURI DE COMPRIMARE
       Suportul pentru niveluri al ZLIB a fost adaugat in v4.14, LZO nu ofera
       suport pentru niveluri (implementarea nucleului ofera doar unul),
       suportul pentru niveluri ZSTD a fost adaugat in v5.1, iar nivelurile
       negative in v6.15.

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

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

       Nivelul 0 corespunde intotdeauna valorii implicite. Nivelul de
       comprimare nu afecteaza compatibilitatea.

EXCEP<?>III
       Orice fi<?>ier care a fost modificat de apelul de sistem fallocate va
       fi intotdeauna exclus de la comprimare, chiar daca se utilizeaza
       op<?>iunea de montare force-compress.

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

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

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

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

       Exista doua modalita<?>i de detectare a datelor incomprehensibile:

       o incercarea efectiva de comprimare - datele sunt comprimate, daca
         rezultatul nu este mai mic, este eliminat, deci acest lucru depinde
         de algoritm <?>i de nivel

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

          $ lsattr fi<?>ier
          ---------------------m fi<?>ier

       Nu se recomanda utilizarea comprimarii for<?>ate, euristica ar trebui
       sa decida acest lucru, iar algoritmii de comprimare detecteaza intern
       de asemenea datele incomprehensibile.

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

       Testele efectuate s-au bazat pe urmatoarele: e<?>antionarea datelor,
       detectarea modelelor repetate pe termen lung, frecven<?>a octe<?>ilor,
       entropia Shannon.

COMPATIBILITATE
       Comprimarea necesita atat sumele de control ale datelor, cat <?>i COW,
       astfel incat 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
       intotdeauna la citirile stocate in memoria tampon.

       Comportamentul scrierii de In/Ie<?> directe depinde de fanionul
       nodului-i. Pentru nodurile cu suma de control a datelor, scrierile de
       In/Ie<?> directe revin intotdeauna la scrierile in tampon, putand
       astfel genera date comprimate daca op<?>iunea de montare/fanioanele
       nodului-i permit acest lucru.

       Pentru nodurile-i fara 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 adauga<?>i de-a lungul timpului, astfel
       incat trebuie luata in considerare <?>i compatibilitatea versiunilor,
       impreuna cu alte instrumente care pot accesa datele comprimate, cum ar
       fi incarcatoarele de pornire.

INTERFA<?>A SYSFS
       Btrfs are o interfa<?>a sysfs pentru a oferi op<?>iuni suplimentare.

       Ruta de nivel superior este /sys/fs/btrfs/, iar structura principala a
       directorului este urmatoarea:

         +--------------------------------+---------------------+----------+
         |Ruta relativa                   | Descriere           | Versiune |
         +--------------------------------+---------------------+----------+
         |features/                       | Toate func<?>iile   | 3.14     |
         |                                | acceptate           |          |
         +--------------------------------+---------------------+----------+
         |<UUID>/                         | UUID-ul sistemului  | 3.14     |
         |                                | de fi<?>iere montat |          |
         +--------------------------------+---------------------+----------+
         |<UUID>/allocation/              | Informa<?>ii        | 3.14     |
         |                                | privind alocarea    |          |
         |                                | spa<?>iului         |          |
         +--------------------------------+---------------------+----------+
         |<UUID>/bdi/                     | Informa<?>ii despre | 5.9      |
         |                                | dispozitivul de     |          |
         |                                | copie de rezerva    |          |
         |                                | (writeback)         |          |
         +--------------------------------+---------------------+----------+
         |<UUID>/devices/<ID_DISPOZITIV>/ | Legatura simbolica  | 5.6      |
         |                                | catre fiecare       |          |
         |                                | dispozitiv bloc     |          |
         |                                | sysfs               |          |
         +--------------------------------+---------------------+----------+
         |<UUID>/devinfo/<ID_DISPOZITIV>/ | Informa<?>ii        | 5.6      |
         |                                | specifice Btrfs     |          |
         |                                | pentru fiecare      |          |
         |                                | dispozitiv          |          |
         +--------------------------------+---------------------+----------+
         |<UUID>/discard/                 | Renun<?>a la        | 6.1      |
         |                                | statistici <?>i     |          |
         |                                | parametri reglabili |          |
         +--------------------------------+---------------------+----------+
         |<UUID>/features/                | Caracteristici ale  | 3.14     |
         |                                | sistemului de       |          |
         |                                | fi<?>iere           |          |
         +--------------------------------+---------------------+----------+
         |<UUID>/qgroups/                 | Informa<?>ii        | 5.9      |
         |                                | globale despre      |          |
         |                                | qgroup              |          |
         +--------------------------------+---------------------+----------+
         |<UUID>/qgroups/<NIVEL>_<ID>/    | Informa<?>ii pentru | 5.9      |
         |                                | fiecare qgroup      |          |
         +--------------------------------+---------------------+----------+
       Pentru directorul /sys/fs/btrfs/features/, fiecare fi<?>ier reprezinta
       o caracteristica acceptata de nucleul actual. Majoritatea fi<?>ierelor
       au valoarea 0. In caz contrar, depinde de fi<?>ier, valoarea 1 inseamna
       de obicei ca caracteristica poate fi activata pe un sistem de fi<?>iere
       montat.

       Pentru directorul /sys/fs/btrfs/<UUID>/features/, fiecare fi<?>ier
       reprezinta o func<?>ie activata pe sistemul de fi<?>iere montat.

       Caracteristicile au acela<?>i nume in sec<?>iunea CARACTERISTICI ALE
       SISTEMULUI DE FI<?>IERE.

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

       bg_reclaim_threshold
              (RW, incepand cu: 5.19)

              Procentul spa<?>iului utilizat din spa<?>iul total al
              dispozitivului pentru a incepe revendicarea automata a grupului
              de blocuri. In principal pentru dispozitive de impar<?>ite in
              zone (zoned).

       checksum
              (RO, incepand cu: 5.5)

              Suma de control utilizata pentru sistemul de fi<?>iere montat.
              Aceasta include atat tipul de suma de control (consulta<?>i
              sec<?>iunea ALGORITMI DE SUMA DE CONTROL) cat <?>i controlorul
              implementat (indica in principal daca este accelerat hardware).

       clone_alignment
              (RO, incepand cu: 3.16)

              Alinierea octe<?>ilor pentru ioctl-urile clone <?>i dedupe.

       commit_stats
              (RW, incepand cu: 6.0)

              Statisticile de performan<?>a pentru confirmarea tranzac<?>iilor
              btrfs de la prima montare. In principal pentru scopuri de
              depanare.

              Scrierea in acest fi<?>ier va reini<?>ializa durata maxima de
              comitere (max_commit_ms) la 0. Fi<?>ierul arata astfel:

                 commits 70649
                 last_commit_ms 2
                 max_commit_ms 131
                 total_commit_ms 170840

              o commits - numarul de tranzac<?>ii comise de la prima montare

              o last_commit_ms - durata in milisecunde a ultimei comiteri

              o max_commit_ms - timpul maxim necesar pentru comiterea unei
                tranzac<?>ii de la prima montare sau ultima repornire

              o total_commit_ms - suma tuturor timpilor de comitere a
                tranzac<?>iilor

       exclusive_operation
              (RO, incepand cu: 5.10)

              Afi<?>eaza opera<?>ia exclusiva in curs de execu<?>ie.
              Consulta<?>i sec<?>iunea OPERA<?>II EXCLUSIVE ALE SISTEMULUI DE
              FI<?>IERE pentru detalii.

       generation
              (RO, incepand cu: 5.11)

              Afi<?>eaza genera<?>ia sistemului de fi<?>iere montat.

       label  (RW, incepand cu: 3.14)

              Afi<?>eaza eticheta curenta a sistemului de fi<?>iere montat.

       metadata_uuid
              (RO, incepand cu: 5.0)

              Afi<?>eaza metadatele UUID ale sistemului de fi<?>iere montat.
              Vede<?>i caracteristica metadata_uuid pentru mai multe detalii.

       nodesize
              (RO, incepand cu: 3.14)

              Afi<?>eaza dimensiunea nodului sistemului de fi<?>iere montat.

       quota_override
              (RW, incepand cu: 4.13)

              Afi<?>eaza starea actuala a depa<?>irii cotei.  0 inseamna ca nu
              exista depa<?>ire a cotei.  1 inseamna depa<?>ire a cotei, cota
              poate ignora configurarile limita existente.

       read_policy
              (RW, incepand cu: 5.11)

              Afi<?>eaza politica actuala de echilibrare pentru citiri.  In
              prezent, este acceptat doar pid (echilibrare folosind valoarea
              ID-ului procesului (pid)). Mai multe politici de echilibrare
              sunt disponibile in versiunea experimentala, <?>i anume
              round-robin.

       sectorsize
              (RO, incepand cu: 3.14)

              Afi<?>eaza dimensiunea sectorului sistemului de fi<?>iere
              montat.

       temp_fsid
              (RO, incepand cu: 6.7)

              Indica faptul ca acest sistem de fi<?>iere a primit un FSID
              temporar in momentul montarii, facand posibila montarea
              dispozitivelor cu acela<?>i FSID.

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

       global_rsv_reserved
              (RO, incepand cu: 3.14)

              Octe<?>ii utiliza<?>i din reserva globala.

       global_rsv_size
              (RO, incepand cu: 3.14)

              Dimensiunea totala a rezervarii globale.

       data/, metadata/ <?>i system/ directoare
              (RO, incepand 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, incepand cu: 5.19)

              Procentul de spa<?>iu recuperabil din dimensiunea grupului de
              blocuri (excluzand spa<?>iul inutilizabil permanent) pentru a
              recupera grupul de blocuri. Poate fi utilizat pe dispozitive
              obi<?>nuite sau de impar<?>ite in zone (zoned).

       bytes_*
              (RO)

              Valorile structurilor de date corespunzatoare pentru tipul <?>i
              profilul grupului de blocuri dat, care sunt utilizate intern
              <?>i se pot modifica rapid in func<?>ie de sarcina.

              Lista completa: bytes_may_use, bytes_pinned, bytes_readonly,
              bytes_reserved, bytes_used, bytes_zone_unusable

       chunk_size
              (RW, incepand cu: 6.0)

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

       size_classes
              (RO, incepand cu: 6.3)

              Numarul de grupuri de blocuri dintr-o anumita clasa, pe baza
              unor metode euristice care masoara lungimea, vechimea <?>i
              fragmentarea.

                 none 136
                 small 374
                 medium 282
                 large 93

   UUID/bdi
       Legatura simbolica catre directorul sysfs al informa<?>iilor despre
       dispozitivul de rezerva (BDI), care este legat de procesul <?>i
       infrastructura de scriere inapoi (rescriere).

   UUID/devices
       Fi<?>ierele din directorul /sys/fs/btrfs/<UUID>/devices sunt legaturi
       simbolice denumite dupa nodurile dispozitivelor (de exemplu, sda, dm-0)
       <?>i care indica directorul sysfs al acestora.

   UUID/devinfo
       Directorul con<?>ine subdirectoare denumite dupa 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, incepand cu: 5.14)

              Afi<?>eaza 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, incepand cu: 5.17)

              Afi<?>eaza fsid-ul caruia ii apar<?>ine dispozitivul.  Poate fi
              diferit de UUID daca este un dispozitiv saman<?>a.

       in_fs_metadata
              (RO, incepand cu: 5.6)

              Afi<?>eaza daca s-a gasit dispozitivul.  Ar trebui sa fie
              intotdeauna 1, deoarece daca valoarea devine 0, directorul DEVID
              va fi <?>ters automat.

       missing
              (RO, incepand cu: 5.6)

              Afi<?>eaza daca dispozitivul este considerat lipsa de modulul
              nucleului.

       replace_target
              (RO, incepand cu: 5.6)

              Afi<?>eaza daca dispozitivul este <?>inta inlocuirii.  Daca nu
              se executa nicio inlocuire a dispozitivului, aceasta valoare
              este 0.

       scrub_speed_max
              (RW, incepand cu: 5.14)

              Afi<?>eaza limita de viteza a opera<?>iei ,,scrub" pentru acest
              dispozitiv. Unitatea este octe<?>i/s.  0 inseamna nicio limita.
              Valoarea poate fi definita, dar nu este persistenta.

       writeable
              (RO, incepand cu: 5.6)

              Afi<?>eaza daca dispozitivul este inscriptibil.

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

       enabled
              (RO, incepand cu: 6.1)

              Afi<?>eaza daca qgroup este activat.  De asemenea, daca qgroup
              este dezactivat, directorul qgroups va fi eliminat automat.

       inconsistent
              (RO, incepand cu: 6.1)

              Afi<?>eaza daca numerele qgroup sunt inconsistente.  Daca
              valoarea este 1, se recomanda efectuarea unei noi scanari
              qgroup.

       drop_subtree_threshold
              (RW, incepand cu: 6.1)

              Afi<?>eaza pragul de eliminare a subarborelui pentru a marca
              automat qgroup ca fiind inconsistent.

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

              Valoarea implicita este 3, ceea ce inseamna ca arborii de
              inal<?>ime mica vor fi lua<?>i in considerare in mod
              corespunzator, deoarece acest lucru este suficient de rapid.
              Valoarea a fost 8 pana la versiunea 6.13, in care nicio scadere
              a subarborelui nu poate declan<?>a reanalizarea qgroup, ceea ce
              o face mai pu<?>in utila.

              O valoare mai mica poate reduce volumul de lucru al qgroup, cu
              pre<?>ul unei reanalizari 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, incepand cu: 5.9)

              Afi<?>eaza octe<?>ii de<?>inu<?>i exclusiv de qgroup.

       limit_flags
              (RO, incepand cu: 5.9)

              Afi<?>eaza valoarea numerica a fanionelor de limita.  Daca este
              0, inseamna ca nu este implicata nicio limita.

       max_exclusive
              (RO, incepand cu: 5.9)

              Afi<?>eaza limitele privind octe<?>ii de<?>inu<?>i exclusiv.

       max_referenced
              (RO, incepand cu: 5.9)

              Afi<?>eaza limitele de octe<?>i la care se poate face referire.

       referenced
              (RO, incepand cu: 5.9)

              Afi<?>eaza octe<?>ii la care se face referire ai qgroup.

       rsv_data
              (RO, incepand cu: 5.9)

              Afi<?>eaza octe<?>ii rezerva<?>i pentru date.

       rsv_meta_pertrans
              (RO, incepand cu: 5.9)

              Afi<?>eaza octe<?>ii rezerva<?>i pentru metadatele per
              tranzac<?>ie.

       rsv_meta_prealloc
              (RO, incepand cu: 5.9)

              Afi<?>eaza octe<?>ii rezerva<?>i pentru metadatele prealocate.

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

       discardable_bytes
              (RO, incepand cu: 6.1)

              Arata cantitatea de octe<?>i care pot fi elimina<?>i in modul
              asincron discard <?>i nodiscard.

       discardable_extents
              (RO, incepand cu: 6.1)

              Afi<?>eaza numarul de extinderi (extents) care urmeaza sa fie
              eliminate in modul async discard <?>i nodiscard.

       discard_bitmap_bytes
              (RO, incepand cu: 6.1)

              Afi<?>eaza cantitatea de octe<?>i elimina<?>i din datele
              urmarite ca bitmaps.

       discard_extent_bytes
              (RO, incepand cu: 6.1)

              Afi<?>eaza cantitatea de extinderi (extents) eliminate din
              datele urmarite ca bitmaps.

       discard_bytes_saved
              (RO, incepand cu: 6.1)

              Afi<?>eaza cantitatea de octe<?>i care au fost realoca<?>i fara
              a fi elimina<?>i.

       kbps_limit
              (RW, incepand cu: 6.1)

              Limita reglabila de kiloocte<?>i pe secunda emisa ca IO discard
              in modul async discard.

       iops_limit
              (RW, incepand cu: 6.1)

              Limita reglabila a numarului de opera<?>ii de IO discard care
              urmeaza sa fie emise in modul asincron discard.

       max_discard_size
              (RW, incepand cu: 6.1)

              Limita reglabila pentru dimensiunea unei cereri de IO discard.

OPERA<?>II EXCLUSIVE ALE SISTEMULUI DE FI<?>IERE
       Exista mai multe opera<?>ii care afecteaza intregul sistem de fi<?>iere
       <?>i nu pot fi rulate in paralel. Incercarea de a porni una in timp ce
       alta este in curs de execu<?>ie va e<?>ua (vede<?>i excep<?>iile de mai
       jos).

       Incepand cu nucleul 5.10, opera<?>ia care ruleaza in prezent poate fi
       ob<?>inuta din /sys/fs/UUID/exclusive_operation cu urmatoarele valori
       <?>i opera<?>ii:

       o balance

       o balance paused (since 5.17)

       o device add

       o device delete

       o device replace

       o resize

       o swapfile activate

       o none

       Inscrierea in coada este acceptata pentru mai multe sub-comenzi btrfs,
       astfel incat acestea sa poata fi lansate simultan <?>i apoi
       serializate.

       Exista o excep<?>ie atunci cand o echilibrare pusa in pauza permite
       inceperea unei opera<?>ii de adaugare a unui dispozitiv, deoarece
       acestea nu se ciocnesc cu adevarat <?>i acest lucru poate fi folosit
       pentru a adauga mai mult spa<?>iu pentru ca echilibrarea sa se incheie.

LIMITE ALE SISTEMULUI DE FI<?>IERE

       maximum file name length
              255

              Aceasta limita este impusa de Linux VFS, structurile BTRFS
              putand 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 datorita limitei sistemului
              PATH_MAX

              <?>inta legaturii simbolice (symlink) poate sa nu fie o ruta
              valida, adica componentele numelui rutei pot depa<?>i limitele
              (NAME_MAX), nu exista validare de con<?>inut la crearea
              symlink(3) <https://man7.org/linux/man-pages/man3/symlink.3
              .html>.

       maximum number of inodes
              264 dar depinde de spa<?>iul disponibil pentru metadate deoarece
              nodurile-i sunt create dinamic

              Fiecare sub-volum este un spa<?>iu de nume independent de
              noduri-i <?>i, prin urmare de numarul acestora, astfel incat
              limita este pentru fiecare sub-volum, nu pentru intregul sistem
              de fi<?>iere.

       inode numbers
              numar minim: 256 (pentru subvolume), fi<?>iere <?>i directoare
              obi<?>nuite: 257, numar maxim: (264 - 256)

              Numerele de noduri-i care pot fi atribuite fi<?>ierelor create
              de utilizator provin din intregul 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 inerenta a BTRFS este 264 (16 Eio), dar limita practica a
              Linux VFS este 263 (8 Eio)

       maximum number of subvolumes
              id-urile sub-volumelor pot ajunge pana la 248, dar numarul
              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 intreg intervalul de 64 de bi<?>i din cauza
              qgroups care utilizeaza cei 16 bi<?>i superiori in alte scopuri.

       maximum number of hardlinks of a file in a directory
              65536 atunci cand func<?>ia extref este activata in timpul mkfs
              (implicit), aproximativ 100 in caz contrar <?>i depinde de
              lungimea numelui de fi<?>ier care se potrive<?>te intr-un nod de
              metadate

       minimum filesystem size
              dimensiunea minima a fiecarui dispozitiv depinde de
              caracteristica mixed-bg, fara aceasta (implicit) este de
              aproximativ 109Mio, cu mixed-bg este de 16Mio

SUPORT PENTRU INCARCATORUL DE PORNIRE
       GRUB2 (%<https://www.gnu.org/software/grub>) are cel mai avansat suport
       pentru pornirea de pe BTRFS in ceea ce prive<?>te caracteristicile.

       U-Boot (%<https://www.denx.de/wiki/U-Boot/>) ofera suport decent pentru
       pornire, dar nu toate func<?>iile BTRFS sunt implementate. Consulta<?>i
       documenta<?>ia.

       In general, primul 1Mio de pe fiecare dispozitiv este neutilizat, cu
       excep<?>ia super-blocului primar care se afla la pozi<?>ia 64Kio <?>i
       se intinde pe 4Kio. Restul poate fi utilizat liber de incarcatoarele de
       pornire sau pentru alte informa<?>ii de sistem. Re<?>ine<?>i ca
       pornirea de pe un sistem de fi<?>iere de pe dispozitivul impar<?>it in
       zone (zoned) <> nu este acceptata.

ATRIBUTELE FI<?>IERELOR
       Sistemul de fi<?>iere btrfs accepta configurarea atributelor sau
       fanioanelor fi<?>ierelor. Re<?>ine<?>i ca exista interfe<?>e vechi <?>i
       noi, cu denumiri confuze. Lista urmatoare ar trebui sa clarifice acest
       aspect:

       o atribute: chattr(1) <https://man7.org/linux/man-pages/man1/chattr.1
         .html> sau lsattr(1) <https://man7.  org/linux/man-pages/man1/lsattr
         .1.html> utilita<?>i (ioctl-urile sunt FS_IOC_GETFLAGS <?>i
         FS_IOC_SETFLAGS), datorita numelor ioctl-urilor atributele sunt
         numite <?>i fanioane

       o xflags: to distinguish from the previous, it's extended flags, with
         tunable bits similar to the attributes but extensible and new bits
         will be added in the future (the ioctls are FS_IOC_FSGETXATTR and
         FS_IOC_FSSETXATTR but they are not related to extended attributes
         that are also called xattrs), there's no standard tool to change the
         bits, there's support in xfs_io(8) <https://man7.org/linux/man-pages/
         man8/xfs_io.8.html> as command xfs_io -c chattr

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

   Atribute

       a      (fi<?>ier, director, radacina) append only, noile scrieri sunt
              intotdeauna scrise la sfar<?>itul fi<?>ierului

       A      (fi<?>ier, director)  no atime updates

       c      (fi<?>ier, director, mo<?>tenit)  compress data, toate datele
              scrise dupa activarea acestui atribut vor fi comprimate.  Va
              rugam sa re<?>ine<?>i ca comprimarea este afectata <?>i de
              op<?>iunile de montare sau de atributele directorului parinte.

              Atunci cand este definit pe un director, toate fi<?>ierele nou
              create vor mo<?>teni acest atribut.  Acest atribut nu poate fi
              definit in acela<?>i timp cu 'm'.

       C      (fi<?>ier, director, mo<?>tenit)  no copy-on-write, modificarile
              datelor din fi<?>iere sunt efectuate pe loc (direct)

              Cand este definit pentru un director, toate fi<?>ierele nou
              create vor mo<?>teni acest atribut.

              Nota:
                 Din cauza limitarilor de implementare, acest fanion poate fi
                 activat/dezactivat numai pentru fi<?>ierele goale.

       d      (fi<?>ier)  no dump, are sens cu instrumente ter<?>e precum
              dump(8) <https://man7.org/linux/man-pages/man8/dump.8.html>, pe
              BTRFS atributul poate fi activat/dezactivat dar nu se face nicio
              alta manipulare speciala

       D      (director)  synchronous directory updates, pentru mai multe
              detalii cauta<?>i open(2) <https://man7.org/linux/man-pages/
              man2/open.2.html> pentru O_SYNC <?>i O_DSYNC

       i      (fi<?>ier, director, root)  immutable, nicio modificare a
              datelor <?>i metadatelor fi<?>ierelor nu este permisa nici macar
              utilizatorului root atata timp cat acest atribut este activat
              (evident, excep<?>ia este dezactivarea atributului)

       m      (fi<?>ier, director)  no compression, dezactiveaza definitiv
              comprimarea pe fi<?>ierul dat. Orice op<?>iuni de montare a
              comprimarii nu vor afecta acest fi<?>ier. (chattr(1) <https://
              man7.org/linux/man-pages/man1/chattr.1.html> suport adaugat in
              versiunea 1.46.2)

              Atunci cand este definit pentru un director, toate fi<?>ierele
              nou create vor mo<?>teni acest atribut.  Acest atribut nu poate
              fi definit in acela<?>i timp cu c.

       S      (fi<?>ier)  synchronous updates, pentru mai multe detalii
              cauta<?>i open(2) <https://man7.org/linux/man-pages/man2/open.2
              .html> pentru O_SYNC <?>i O_DSYNC

       V      (fi<?>ier, numai-citire)  fs-verity enabled pe fi<?>ier

       Nu sunt acceptate alte atribute.  Pentru lista completa, consulta<?>i
       pagina de manual chattr(1) <https://man7.org/linux/man-pages/man1/
       chattr.1.html>.

   XFLAGS
       Exista o suprapunere de litere atribuite bi<?>ilor cu atribute, aceasta
       lista se refera la ceea ce ofera xfs_io(8) <https://man7:.org/linux/
       man-pages/man8/xfs_io.8:.html>:

       i      immutable, la fel ca atributul

       a      append only, la fel ca atributul

       s      synchronous updates, la fel ca atributul S

       A      no atime updates, la fel ca atributul

       d      no dump, la fel ca atributul

MODUL ,,ZONED" (de impar<?>ire in 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, in modul host-managed.
       Re<?>ine<?>i ca exista dispozitive care apar ca neimpar<?>ite in zone,
       dar care sunt de fapt de impar<?>ite in zone. Acestea sunt
       drive-managed <?>i utilizarea modului ,,zoned" (de impar<?>ire in zone(
       nu va ajuta.

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

   Cerin<?>e, limitari

       o toate dispozitivele trebuie sa aiba aceea<?>i dimensiune a zonei

       o dimensiunea maxima a zonei este de 8 Gio

       o dimensiunea minima a zonei este de 4 Mio

       o amestecarea dispozitivelor impar<?>ite in zone <?>i a celor
         neimpar<?>ite in zone este posibila, scrierile zonale sunt emulate,
         dar acest lucru este in special pentru testare

       o super-blocul este tratat intr-un mod special <?>i se afla in
         loca<?>ii diferite fa<?>a de un sistem de fi<?>iere neimpar<?>it in
         zone:

         o primar: 0octe<?>i (<?>i urmatoarele doua zone)

         o secundar: 512 Gio (<?>i urmatoarele doua zone)

         o ter<?>iar: 4 Tio (4096 Gio <?>i urmatoarele doua zone)

   Caracteristici incompatibile
       Principala constrangere a dispozitivelor impar<?>ite in zone este lipsa
       actualizarii pe loc(direct) a datelor. Acest lucru este intrinsec
       incompatibil cu anumite caracteristici:

       o NODATACOW - suprascriere pe loc (directa), nu se pot crea astfel de
         fi<?>iere

       o fallocate - prealocarea spa<?>iului pentru prima scriere pe loc
         (directa)

       o mixed-bg - scrieri neordonate in date <?>i metadate, remedierea
         acestei probleme implica utilizarea unor grupuri separate de blocuri
         de date <?>i metadate

       o booting - zona la pozi<?>ia 0 con<?>ine super-blocul,
         reini<?>ializarea zonei ar distruge datele incarcatorului de pornire

       Suportul ini<?>ial nu dispune de anumite func<?>ii, dar acestea sunt
       planificate:

       o este acceptat numai profilul unic (date, metadate) <?>i DUP
         (metadate)

       o fstrim - din cauza dependen<?>ei de cache-ul spa<?>iului liber v1

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

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

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

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

       Acest proces poate dura ceva timp, in func<?>ie de alte opera<?>ii din
       fundal sau de cantitatea de date noi scrise. Este posibil sa se produca
       o eroare ENOSPC intermitenta. Unele dispozitive limiteaza, de asemenea,
       numarul de zone active.

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

       Nota: modul de impar<?>ire in zone nu func<?>ioneaza cu discurile
       DM-SMR.

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

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

       Configurarea:

          modprobe configfs
          modprobe null_blk nr_devices=0

       Crea<?>i un dispozitiv mydev, presupunand ca nu exista alte dispozitive
       create anterior, cu dimensiunea de 2048 Mio <?>i dimensiunea zonei de
       256 Mio. Exista mai mul<?>i parametri reglabili, acesta fiind un
       exemplu minim care utilizeaza 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 numarului final al nodului dispozitivului.

       Elimina<?>i dispozitivul:

          rmdir /sys/kernel/config/nullb/mydev

       Apoi continua<?>i cu mkfs.btrfs /dev/nullb0, modul de impar<?>ire in
       zone fiind detectat automat.

       Pentru comoditate, exista un script care cuprinde opera<?>iile de baza
       de gestionare null_blk <https://github.com/kdave/nullb.git>, comenzile
       de mai sus devin:

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

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

   Compatibilitate, incompatibilitate

       o caracteristica stabile<?>te un bit incompat <?>i necesita un nou
         nucleu pentru a accesa sistemul de fi<?>iere (atat pentru citire, cat
         <?>i pentru scriere)

       o superblock needs to be handled in a special way, there are still 3
         copies but at different offsets (0, 512GiB, 4TiB) and the 2
         consecutive zones are a ring buffer of the superblocks, finding the
         latest one needs reading it from the write pointer or do a full scan
         of the zones

       o amestecarea dispozitivelor impar<?>ite in zone <?>i a celor
         neimpar<?>ite in zone este posibila, (zonele sunt emulate), dar acest
         lucru este recomandat doar pentru testare

       o amestecarea dispozitivelor impar<?>ite in zone cu diferite dimensiuni
         ale zonelor, nu este posibila

       o dimensiunile zonelor trebuie sa fie puteri de doi, dimensiunile
         zonelor dispozitivelor reale sunt, de exemplu, 256Mio sau 1Gio, se
         a<?>teapta dimensiuni mai mari, dimensiunea maxima a zonelor
         acceptate de btrfs este 8Gio

   Stare, stabilitate, raportarea erorilor
       Modul de impar<?>ire in zone ,,zoned" a fost lansat in versiunea 5.12
       <?>i exista inca unele imperfec<?>iuni <?>i cazuri speciale care pot
       aparea in timpul testarii. Va rugam sa raporta<?>i erorile la <https://
       github.com/naota/linux/issues/> .

   Referin<?>e

       o <https://zonedstorage.io>

         o <https://zonedstorage.io/projects/libzbc/> -- libzbc este o
           biblioteca <?>i un set de instrumente pentru manipularea directa a
           dispozitivelor cu suport ZBC/ZAC

         o <https://zonedstorage.io/projects/libzbd/> -- libzbd utilizeaza
           interfa<?>a dispozitivului de blocuri impar<?>it in zone furnizata
           de nucleu pe baza apelurilor de sistem ioctl()

       o <https://hddscan.com/blog/2020/hdd-wd-smr.html> -- cateva detalii
         despre tipurile exacte de dispozitive

       o <https://lwn.net/Articles/853308/> -- Btrfs on zoned block devices

       o <https://www.usenix.org/conference/vault20/presentation/bjorling> --
         Zone Append: A New Way of Writing to Zoned Storage

DISPOZITIV DE CONTROL
       Exista un dispozitiv special de caractere /dev/btrfs-control cu
       numerele majore <?>i minore 10 <?>i 234 (dispozitivul poate fi gasit in
       categoria misc).

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

       Dispozitivul accepta unele apeluri ioctl care pot efectua urmatoarele
       ac<?>iuni pe modulul sistemului de fi<?>iere:

       o scanarea dispozitivelor pentru sistemul de fi<?>iere btrfs (de
         exemplu, pentru a permite montarea automata a sistemelor de fi<?>iere
         cu mai multe dispozitive) <?>i inregistrarea acestora cu modulul
         nucleului

       o similar cu scanarea, dar a<?>teapta, de asemenea, pana cand procesul
         de scanare a dispozitivului este finalizat pentru un sistem de
         fi<?>iere specificat

       o ob<?>ine caracteristicile acceptate (pot fi gasite <?>i sub
         /sys/fs/btrfs/features)

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

       In cazuri rare, cand modulul este incarcat, dar dispozitivul nu este
       prezent (cel mai probabil <?>ters accidental), este posibil sa il
       recrea<?>i prin

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

       sau (incepand cu versiunea 5.11) printr-o comanda convenabila

          # btrfs rescue create-control-device

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

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

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

       Rezultatul corespunzator al btrfs filesystem df ar putea arata 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

       Exista mai mult de o linie pentru tipurile Data <?>i Metadata, in timp
       ce profilurile sunt single <?>i RAID1.

       Aceasta stare a sistemului de fi<?>iere este OK, dar cel mai probabil
       este nevoie ca utilizatorul/administratorul sa intreprinda o ac<?>iune
       <?>i sa finalizeze sarcinile intrerupte. Acest lucru nu poate fi facut
       cu u<?>urin<?>a in mod automat, de asemenea, utilizatorul cunoa<?>te
       profilurile finale a<?>teptate.

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

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

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

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

          Multiple profiles:                 yes (data, metadata)

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

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

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

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

          Acest lucru este menit sa asigure ca un dispozitiv de blocuri are un
          singur sistem de fi<?>iere legat de acesta, astfel incat
          evenimentele de lipsa a dispozitivului in timpul rularii sa poata fi
          gestionate corespunzator.

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

       Nota:
          A existat o eroare cunoscuta cu utilizarea opaiunii ,,remount"
          pentru a face montarea inscriptibila: ,,remount" va lasa sistemul de
          fi<?>iere intr-o stare in care nu este capabil sa cure<?>e
          instantaneele <?>terse, astfel incat acesta va pierde spa<?>iu pana
          cand este demontat <?>i montat corect.

          Aceasta eroare a fost remediata in versiunile 5.11 <?>i mai recente
          ale nucleului.

       In plus, <?>tergerea dispozitivului de insaman<?>are din sistemul de
       fi<?>iere il poate transforma intr-un sistem de fi<?>iere normal, cu
       condi<?>ia ca dispozitivul inscriptibil sa poata con<?>ine <?>i toate
       datele din dispozitivul de insaman<?>are.

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

       Exemplu de creare <?>i utilizare a unui dispozitiv de insaman<?>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 inscriptibila

       Acum /mnt/mnt1 poate fi utilizat in 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 inscriptibila

       Dispozitivul inscriptibil (file:/dev/sdb) poate fi decuplat de
       dispozitivul de insaman<?>are <?>i utilizat independent:

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

       Deoarece con<?>inutul provine din dispozitivul de insaman<?>are, este
       posibil sa transforma<?>i /dev/sdb din nou intr-un dispozitiv de
       insaman<?>are <?>i sa repeta<?>i intregul proces.

       Cateva lucruri de re<?>inut:

       o se recomanda utilizarea unui singur dispozitiv pentru dispozitivul de
         insaman<?>are, func<?>ioneaza pentru mai multe dispozitive, dar
         profilul single trebuie utilizat pentru a face ca <?>tergerea
         dispozitivului de insaman<?>are sa func<?>ioneze

       o profilele grupurilor de blocuri single <?>i dup ofera suport pentru
         cazurile de utilizare de mai sus

       o eticheta este copiata de la dispozitivul de insaman<?>are <?>i poate
         fi modificata prin btrfs filesystem label

       o fiecare noua montare a dispozitivului de insaman<?>are prime<?>te un
         nou UUID aleatoriu

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

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

          # mkfs.btrfs /dev/sda
          # mount /dev/sda /mnt/mnt1
          ... fill mnt1 with data
          # umount /mnt/mnt1

          # btrfstune -S 1 /dev/sda

          # mount /dev/sda /mnt/mnt1
          # btrfs device add /dev/sdb /mnt/mnt1
          # mount -o remount,rw /mnt/mnt1
          ... /mnt/mnt1 este acum inscriptibila
          # 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 inscriptibila
          # umount /mnt/mnt1

       Ca rezultat, avem:

       o sda este un singur dispozitiv de insaman<?>are, cu con<?>inutul sau
         ini<?>ial

       o sdb este un dispozitiv de insaman<?>are, dar necesita sda,
         con<?>inutul este din momentul in care sdb este facut insaman<?>are,
         adica con<?>inutul lui sda cu orice modificari ulterioare

       o sdc ultimul inscriptibil, poate fi transformat intr-unul de
         insaman<?>are la fel cum a fost sdb, pastrandu-i con<?>inutul <?>i
         depinzand de sda <?>i sdb

       Atat timp cat dispozitivele de insaman<?>are sunt nemodificate <?>i
       disponibile, acestea pot fi utilizate pentru a crea o alta ramura.

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

   Metadate
       Nu utiliza<?>i raid5 sau raid6 pentru metadate. Utiliza<?>i raid1 sau,
       respectiv, raid1c3.

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

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

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

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

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

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

GLOSAR
       Termenii care apar in cursiva apar <?>i in acest glosar.

       allocator
              De obicei, allocator inseamna alocatorul block, adica logica din
              interiorul sistemului de fi<?>iere care decide unde sa plaseze
              blocurile nou alocate pentru a men<?>ine mai multe constrangeri
              (precum amplasarea datelor, fragmentarea redusa).

              In btrfs, alocatorul se poate referi <?>i la alocatorul chunk,
              adica logica din spatele plasarii buca<?>ilor pe dispozitive.

       balance
              An operation that can be done to a btrfs filesystem, for example
              through btrfs balance /path. A balance passes all data in the
              filesystem through the allocator again. It is primarily intended
              to rebalance the data in the filesystem across the devices when
              a device is added or removed. A balance will regenerate missing
              copies for the redundant RAID levels, if a device has failed. As
              of Linux kernel 3.3, a balance operation can be made selective
              about which parts of the filesystem are rewritten using filters
              <#man-balance-filters>.

       barrier
              An instruction to the underlying hardware to ensure that
              everything before the barrier is physically written to permanent
              storage before anything after it. Used in btrfs's copy on write
              approach to ensure filesystem consistency.

       block  O singura piesa de stocare contigua din punct de vedere fizic
              <?>i logic pe un dispozitiv, de dimensiune, de exemplu, 4K. In
              unele contexte, se face referire <?>i la sector, de<?>i este
              preferat termenul block.

       block group
              The unit of allocation of space in btrfs. A block group is laid
              out on the disk by the btrfs allocator, and will consist of one
              or more chunks, each stored on a different device. The number of
              chunks used in a block group will depend on its RAID level.

       B-tree The fundamental storage data structure used in btrfs. Except for
              the superblocks, all of btrfs metadata is stored in one of
              several B-trees on disk. B-trees store key/item pairs. While the
              same code is used to implement all of the B-trees, there are a
              few different categories of B-tree. The name btrfs refers to its
              use of B-trees.

       btrfsck, fsck, btrfs-check
              Tool in btrfs-progs that checks an unmounted filesystem
              (offline)  and reports on any errors in the filesystem
              structures it finds.  By default the tool runs in read-only mode
              as fixing errors is potentially dangerous.  See also scrub.

       btrfs-progs
              User mode tools to manage btrfs-specific features. Maintained at
              <http://github.com/kdave/btrfs-progs.git> . The main frontend to
              btrfs features is the standalone tool btrfs, although other
              tools such as mkfs.btrfs and btrfstune are also part of
              btrfs-progs.

       chunk  O parte a unui block group. Buca<?>ile au dimensiunea de 1 Gio
              (pentru date) sau 256 Mio (pentru metadata), in func<?>ie de
              dimensiunea totala a sistemului de fi<?>iere.

       chunk tree
              Un strat care pastreaza informa<?>ii despre coresponden<?>a
              dintre adresele blocurilor fizice <?>i logice. Acesta este
              stocat in cadrul grupului system.

       cleaner
              Usually referred to in context of deleted subvolumes. It's a
              background process that removes the actual data once a subvolume
              has been deleted.  Cleaning can involve lots of IO and CPU
              activity depending on the fragmentation and amount of shared
              data with other subvolumes.

              Firul de execu<?>ie mai curat al nucleului proceseaza, de
              asemenea, defragmentarea declan<?>ata de op<?>iunea de montare
              autodefrag, eliminarea grupurilor de blocuri goale <?>i alte
              cateva sarcini de finalizare.

       copy-on-write, COW
              Also known as COW. The method that btrfs uses for modifying
              data.  Instead of directly overwriting data in place, btrfs
              takes a copy of the data, alters it, and then writes the
              modified data back to a different (unused) location on the disk.
              It then updates the metadata to reflect the new location of the
              data. In order to update the metadata, the affected metadata
              blocks are also treated in the same way. In COW filesystems,
              files tend to fragment as they are modified.  Copy-on-write is
              also used in the implementation of snapshots and reflink copies.
              A copy-on-write filesystem is, in theory, always consistent,
              provided the underlying hardware supports barriers.

       default subvolume
              sub-volumul dintr-un sistem de fi<?>iere btrfs care este montat
              la montarea sistemului de fi<?>iere fara a utiliza op<?>iunea de
              montare subvol=.

       device Un dispozitiv de blocuri Linux, de exemplu, un disc intreg, 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 stocheaza
              chei <?>i date de element. Structurile conexe subiacente sunt un
              bloc de dispozitiv fizic <?>i o pagina de memorie CPU.

       fallocate
              Command line tool in util-linux, and a syscall, that reserves
              space in the filesystem for a file, without actually writing any
              file data to the filesystem. First data write will turn the
              preallocated extents into regular ones. See fallocate(1)
              <https://man7.org/linux/man-pages/man1/fallocate.1.html> and
              fallocate(2) <https://man7.org/linux/man-pages/man2/fallocate.2
              .html> manual pages for more details.

       filefrag
              A tool to show the number of extents in a file, and hence the
              amount of fragmentation in the file. It is usually part of the
              e2fsprogs package on most Linux distributions. While initially
              developed for the ext2 filesystem, it works on Btrfs as well. It
              uses the FIEMAP ioctl.

       free space cache
              Also known as "space cache v1". A separate cache tracking free
              space as btrfs only tracks the allocated space. The free space
              is by definition any hole between allocated ranges. Finding the
              free ranges can be I/O intensive so the cache stores a condensed
              representation of it.  It is updated every transaction commit.

              Memoria cache de spa<?>iu liber v1 a fost inlocuita 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 urmarit intr-un mod
              mai bun <?>i folosind COW, spre deosebire de un mecanism
              personalizat din v1.

       fsync  On Unix and Unix-like operating systems (of which Linux is the
              latter), the fsync(2) <https://man7.org/linux/man-pages/man2/
              fsync.2.html> system call causes all buffered file descriptor
              related data changes to be flushed to the underlying block
              device. When a file is modified on a modern operating system the
              changes are generally not written to the disk immediately but
              rather those changes are buffered in memory for performance
              reasons, calling fsync(2) <https://man7.org/linux/man-pages/
              man2/fsync.2.html> causes any in-memory changes to be written to
              disk.

       generation
              An internal counter which updates for each transaction. When a
              metadata block is written (using copy on write), current
              generation is stored in the block, so that blocks which are too
              new (and hence possibly inconsistent) can be identified.

       key    A fixed sized tuple used to identify and sort items in a B-tree.
              The key is broken up into 3 parts: objectid, type, and offset.
              The type field indicates how each of the other two fields should
              be used, and what to expect to find in the item.

       item   O structura de marime variabila stocata in frunze B-tree.
              Elementele con<?>in diferite tipuri de date in func<?>ie de
              tipul cheii.

       log tree
              Un b-tree care urmare<?>te temporar actualizarile de metadate in
              curs de desfa<?>urare pana cand se efectueaza o comitere
              completa a tranzac<?>iei. Este o optimizare de performan<?>a a
              fsync. Jurnalul urmarit in arbore este reluat daca sistemul de
              fi<?>iere nu este demontat curat.

       metadata
              Date despre date. In 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 fiecarui fi<?>ier. Toate
              metadatele btrfs sunt stocate in 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 inca in uz (deschis de un proces in
              desfa<?>urare), dar toate intrarile 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 forma de RAID care nu ofera garan<?>ii de recuperare in caz de
              eroare, dar realizeaza o singura copie a datelor pe mai multe
              dispozitive in scopuri de performan<?>a. Dimensiunea benzii
              (stripe) este fixata 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 forma de RAID care imparte o singura copie a datelor pe mai
              multe dispozitive, inclusiv datele de paritate suplimentare ale
              unui dispozitiv.  Poate fi utilizata pentru recuperarea datelor
              in cazul defectarii unui singur dispozitiv.

       RAID6  O forma de RAID care imparte o singura copie a datelor pe mai
              multe dispozitive, inclusiv date de paritate suplimentare
              echivalente cu doua dispozitive. Poate fi utilizata pentru
              recuperarea datelor in cazul defectarii a doua dispozitive.

       RAID10 O forma de RAID care stocheaza doua copii complete ale fiecarei
              date <?>i, de asemenea, imparte fiecare copie pe mai multe
              dispozitive pentru a imbunata<?>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 in cadrul sistemului
              de fi<?>iere, men<?>inand in acela<?>i timp integritatea <?>i
              coeren<?>a completa a sistemului de fi<?>iere. Aceasta
              func<?>ionalitate sta 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, verifica sumele de control <?>i, in cele din urma,
              utilizeaza 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 stocheaza o singura copie a
              fiecarei 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 in partea de sus a sistemului de fi<?>iere. Acesta
              este singurul subvolum prezent intr-un sistem de fi<?>iere btrfs
              nou creat <?>i are ID-ul 5 intern, altfel ar putea fi referit ca
              0 (de exemplu, in 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 in contextul nucleului Linux poate fi definit ca
              procesul de scriere a memoriei ,,murdare" din cache-ul paginii
              pe disc, atunci cand sunt indeplinite anumite condi<?>ii
              (expirarea timpului, numarul 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 intr-un spa<?>iu de stocare a datelor. Un sistem
       de fi<?>iere este structura logica care organizeaza 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 in considerare urmatoarele ipoteze privind dispozitivele de
       stocare (ordonate dupa importan<?>a, numerele sunt pentru referin<?>e
       ulterioare):

       1. atomicitatea citirilor <?>i scrierilor de blocuri/sectoare (cea mai
          mica unitate de date pe care dispozitivul o prezinta straturilor
          superioare)

       2. exista o comanda de golire care instruie<?>te dispozitivul sa
          ordoneze in mod for<?>at scrierile inainte <?>i dupa comanda;
          alternativ, exista o comanda de bariera care faciliteaza ordonarea,
          dar care poate sa nu goleasca datele

       3. datele trimise pentru a fi scrise intr-o anumita pozi<?>ie pe un
          dispozitiv vor fi scrise fara modificari suplimentare ale datelor
          <?>i ale pozi<?>iei

       4. scrierile pot fi reordonate de dispozitiv, cu excep<?>ia cazului in
          care sunt serializate in mod explicit prin comanda flush

       5. citirile <?>i scrierile pot fi reordonate <?>i intercalate in 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.

   Cand lucrurile merg prost
       Atomicitate nula sau par<?>iala a citirilor/scrierilor in bloc (1)

       o Problema: con<?>inutul unui bloc par<?>ial este scris (scriere
         intrerupta), de exemplu din cauza unei intreruperi de curent sau a
         unei alte defec<?>iuni electronice in timpul citirii/scrierii.

       o Detectare: nepotrivire suma de control la citire

       o Reparare: utiliza<?>i o alta copie sau reconstrui<?>i din mai multe
         blocuri utilizand o schema de codificare

       Comanda flush nu efectueaza 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 in mod silen<?>ios la scriere (3)

       Astfel de lucruri nu ar trebui sa se intample frecvent, dar pot aparea
       in mod nea<?>teptat din cauza func<?>ionarii interne complexe a
       dispozitivelor sau a efectelor fizice ale suportului de stocare in
       sine.

       o Problema: in timp ce datele sunt scrise atomic, con<?>inutul se
         modifica

       o Detectare: nepotrivire suma de control la citire

       o Reparare: utiliza<?>i o alta copie sau reconstrui<?>i din mai multe
         blocuri utilizand o schema de codificare

       Datele sunt scrise in mod silen<?>ios intr-o alta pozi<?>ie (3)

       Aceasta ar fi o alta problema grava, deoarece sistemul de fi<?>iere nu
       are informa<?>ii cand se intampla acest lucru. Din acest motiv,
       masurile trebuie luate din timp.  Aceasta problema este denumita in mod
       obi<?>nuit ghost write (scriere fantoma).

       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.

       Urmatoarele informa<?>ii se bazeaza pe informa<?>ii disponibile public,
       comentarii/opinii ale utilizatorilor, discu<?>ii in comunitate sau
       analize ale rapoartelor de erori. Acestea nu sunt complete <?>i, in caz
       de dubiu, se recomanda efectuarea de cercetari suplimentare.

   Memoria principala
       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<?>a (cum ar fi RAID1) nu
       protejeaza impotriva erorilor de memorie, deoarece blocurile sunt mai
       intai stocate in memorie inainte de a fi scrise pe dispozitive din
       aceea<?>i sursa.

       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:

       o <https://en.wikipedia.org/wiki/Row_hammer>

       o overclocking-ul memoriei, XMP, riscuri poten<?>iale

       Ce trebuie facut:

       o rula<?>i memtest, re<?>ine<?>i ca uneori erorile de memorie apar
         numai atunci cand sistemul este supus unei sarcini mari, pe care
         memtest-ul implicit nu o poate declan<?>a

       o erorile de memorie pot aparea ca sistem de fi<?>iere care devine
         numai pentru citire din cauza verificarii ,,pre-scriere", care
         verifica metadatele inainte ca acestea sa fie scrise, dar e<?>ueaza
         la unele verificari de consisten<?>a de baza

       o sistemele nou construite ar trebui testate inainte de a fi utilizate
         in produc<?>ie, in mod ideal pornind o sarcina IO/CPU care va fi
         rulata ulterior pe un astfel de sistem; mai precis sistemele care vor
         utiliza overclocking sau caracteristici speciale de performan<?>a

   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.

       Exista multe particularita<?>i (solu<?>ii specifice dispozitivelor) in
       controlorii nucleului Linux (nu numai in ceea ce prive<?>te DMA) care
       sunt adaugate atunci cand sunt descoperite. Particularita<?>ile pot
       evita anumite erori sau pot dezactiva unele func<?>ii pentru a evita
       probleme mai grave.

       Ce trebuie facut:

       o utiliza<?>i un nucleu actualizat (versiuni recente sau versiuni cu
         suport pe termen lung)

       o 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 facut:

       o rula<?>i smartctl pentru a identifica poten<?>ialele probleme

   Unita<?>i de stocare in stare solida (,,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.

       Exista mai multe tehnologii <?>i producatori, astfel incat este dificil
       sa le descriem, dar unele dintre ele prezinta un comportament similar:

       o SSD-urile scumpe utilizeaza celule de memorie mai durabile <?>i sunt
         optimizate pentru fiabilitate <?>i sarcina mare

       o SSD-urile ieftine sunt proiectate pentru o incarcare mai mica
         (,,utilizatori casnici") <?>i sunt optimizate din punct de vedere al
         costurilor, putand utiliza optimizarile <?>i/sau raportarea extinsa a
         erorilor par<?>ial sau deloc

       Nu este posibil sa se determine in mod fiabil durata de via<?>a
       preconizata a unui SSD din cauza lipsei de informa<?>ii despre modul in
       care func<?>ioneaza sau din cauza lipsei de statistici fiabile
       furnizate de dispozitiv.

       Scrierile de metadate tind sa fie cea mai mare componenta a scrierilor
       pe durata de via<?>a a unui SSD, astfel incat reducerea acestora are o
       anumita valoare. In func<?>ie de clasa dispozitivului (high end/low
       end), caracteristici precum profilurile grupurilor de blocuri DUP pot
       afecta fiabilitatea in ambele sensuri:

       o high end sunt de obicei mai fiabile, iar utilizarea single pentru
         date <?>i metadate ar putea fi potrivita pentru a reduce uzura
         dispozitivului

       o low end ar putea sa nu aiba capacitatea de a identifica erorile,
         astfel incat o redundan<?>a suplimentara 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:

       o <https://www.snia.org/educational-library/
         ssd-and-deduplication-end-spinning-disk-2012>

       o <https://www.snia.org/educational-library/
         realities-solid-state-storage-2013-2013>

       o <https://www.snia.org/educational-library/
         ssd-performance-primer-2013>

       o <https://www.snia.org/educational-library/
         how-controllers-maximize-ssd-life-2013>

       Ce trebuie facut:

       o rula<?>i smartctl sau autotestele pentru a identifica poten<?>ialele
         probleme

       o men<?>ine<?>i firmware-ul actualizat

   Memorie expresa nevolatila 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.

       Intr-un fel, erorile pot fi comparate cu o combina<?>ie intre clasa SSD
       <?>i memoria obi<?>nuita. Erorile pot aparea sub forma de inversari
       aleatoare de bi<?>i sau erori de In/Ie<?>. Exista instrumente pentru
       accesarea jurnalului intern (nvme log <?>i nvme-cli) pentru o analiza
       mai detaliata.

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

       o <https://en.wikipedia.org/wiki/NVM_Express>

       o <https://www.smartmontools.org/wiki/NVMe_Support>

   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 gama larga de corup<?>ii, de la
       cele mici <?>i localizate pana la cele mari, care afecteaza o mul<?>ime
       de date. Capacita<?>ile de autoreparare pot fi insuficiente.

       Ce trebuie facut:

       o verifica<?>i daca exista actualizari de firmware in cazul in care
         exista probleme cunoscute; re<?>ine<?>i ca actualizarea firmware-ului
         poate fi riscanta in sine

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

       Adaugarea de redundan<?>a, cum ar fi utilizarea profilurilor DUP atat
       pentru date, cat <?>i pentru metadate, poate fi utila in unele cazuri,
       dar o copie de rezerva completa ar putea fi cea mai buna op<?>iune
       odata ce apar probleme, iar inlocuirea cardului ar putea fi, de
       asemenea, necesara.

   Hardware-ul ca sursa principala a corup<?>iei sistemului de fi<?>iere
       Daca utiliza<?>i hardware nesigur <?>i nu <?>ti<?>i acest lucru, nu
       da<?>i vina pe sistemul de fi<?>iere cand va avertizeaza.

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

TRADUCERE
       Traducerea in limba romana a acestui manual a fost facuta de Remus-
       Gabriel Chelu <remusgabriel.chelu@disroot.org>

       Aceasta traducere este documenta<?>ie gratuita; citi<?>i Licen<?>a
       publica generala GNU Versiunea 3
       <https://www.gnu.org/licenses/gpl-3.0.html> sau o versiune ulterioara
       cu privire la condi<?>ii privind drepturile de autor.  NU se asuma
       NICIO RESPONSABILITATE.

       Daca gasi<?>i erori in traducerea acestui manual, va rugam sa
       trimite<?>i un e-mail la <translation-team-ro@lists.sourceforge.net>.

6.19                           13 februarie 2026                      BTRFS(5)