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 de impar<?>ire in zone

       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. Aceasta op<?>iune se
              aplica doar la prima montare in modul citire-scriere.

              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 numai-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 accepta comprimarea transparenta a fi<?>ierelor. Sunt disponibili
       trei algoritmi: ZLIB, LZO <?>i ZSTD (incepand cu versiunea 4.14), cu
       diferite niveluri. Comprimarea se realizeaza la nivelul extinderilor
       fi<?>ierelor, iar algoritmul este selectat prin proprieta<?>ile
       fi<?>ierului, op<?>iunile de montare sau prin comanda de defragmentare.
       Pute<?>i avea un singur punct de montare btrfs care con<?>ine unele
       fi<?>iere necomprimate, altele comprimate cu LZO, altele cu ZLIB, de
       exemplu (de<?>i s-ar putea sa nu dori<?>i acest lucru, este acceptat).

       Odata ce comprimarea este activata, toate datele nou scrise vor fi
       comprimate, adica datele existente raman neschimbate. Datele sunt
       impar<?>ite in blocuri mai mici (128 Kio) inainte de comprimare, pentru
       a permite rescrierile aleatorii fara a afecta semnificativ
       performan<?>a. Datorita numarului crescut de extinderi (extents),
       consumul de metadate este mai mare. Blocurile sunt comprimate in
       paralel.

       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

       Diferen<?>ele depind de setul de date concret <?>i nu pot fi exprimate
       printr-o singura valoare numerica sau recomandare. Nivelurile mai
       ridicate consuma mai mult timp de procesare <?>i s-ar putea sa nu aduca
       o imbunata<?>ire semnificativa, in timp ce nivelurile mai scazute se
       afla aproape de timpul real.

CUM SE ACTIVEAZA COMPRIMAREA
       De obicei, comprimarea poate fi activata la nivelul intregului sistem
       de fi<?>iere, fiind specificata pentru punctul de montare. Re<?>ine<?>i
       ca op<?>iunile de montare pentru comprimare sunt comune tuturor
       montarilor aceluia<?>i sistem de fi<?>iere, fie ca este vorba de
       montari de tip ,,bind" sau de montari de sub-volume. Va rugam sa
       consulta<?>i sec<?>iunea <<OP<?>IUNI DE MONTARE>> din btrfs(5).

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

       Aceasta va activa algoritmul zstd la nivelul implicit (care este 3).
       Nivelul poate fi specificat <?>i manual, de exemplu zstd:3. Nivelurile
       mai ridicate ofera o compresie mai buna, dar necesita mai mult timp. La
       randul sau, acest lucru poate duce la o laten<?>a de scriere mai mare;
       nivelurile mai scazute sunt potrivite pentru comprimarea in timp real
       <?>i, pe un procesor suficient de rapid, nu provoaca scaderi
       semnificative ale performan<?>ei.

          $ btrfs filesystem defrag -czstd fi<?>ier

       Comanda de mai sus va ini<?>ia defragmentarea intregului fi<?>ier file
       <?>i va aplica compresia, indiferent de op<?>iunea de montare. Nivelul
       de compresie poate fi specificat <?>i cu argumentul --level sau -L
       incepand cu versiunea 6.14. Algoritmul de compresie nu este persistent
       <?>i se aplica doar comenzii de defragmentare; pentru orice alte
       opera<?>iuni de scriere se aplica alte op<?>iuni de compresie.

       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

       Prima comanda utilizeaza interfa<?>a invechita a atributelor de
       fi<?>ier mo<?>tenita de la sistemul de fi<?>iere ext2 <?>i nu este
       flexibila, a<?>a ca, in mod implicit, este activata comprimarea zlib.
       Cealalta comanda define<?>te o proprietate a fi<?>ierului folosind
       algoritmul specificat. Nota: definirea nivelului in acest mod nu este
       inca implementata.

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.

       Exista 9 niveluri ZLIB acceptate (de la 1 la 9), care corespund unu la
       unu intre op<?>iunea de montare <?>i nivelul definit de algoritm.
       Valoarea implicita este nivelul 3, care ofera un raport de comprimare
       destul de bun <?>i este totu<?>i destul de rapid. Diferen<?>a in ceea
       ce prive<?>te gradul de comprimare intre nivelurile 7, 8 <?>i 9 este
       comparabila, dar nivelurile superioare dureaza mai mult.

       Suportul ZSTD include nivelurile -15..15, un subset al gamei complete
       oferite de ZSTD. Nivelurile -15..-1 sunt in timp real, cu un raport de
       compresie mai slab, nivelurile 1..3 sunt aproape in timp real, cu o
       compresie buna, 4..8 sunt mai lente, cu o compresie imbunata<?>ita, iar
       9..15 depun eforturi <?>i mai mari, de<?>i dimensiunea fi<?>ierului
       rezultat s-ar putea sa nu fie imbunata<?>ita semnificativ. Nivelurile
       mai ridicate necesita, de asemenea, mai multa memorie <?>i, deoarece
       necesita mai multa putere de procesare, performan<?>a sistemului este
       afectata.

       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.

       Motivul este ca o apelare reu<?>ita a func<?>iei fallocate trebuie sa
       garanteze ca viitoarele opera<?>ii de scriere in intervalul alocat nu
       vor e<?>ua din cauza lipsei de spa<?>iu. Acest lucru este dificil de
       garantat intr-un sistem de fi<?>iere COW. Pentru a reduce
       probabilitatea ca acest lucru sa se intample, btrfs pre-aloca spa<?>iu
       <?>i dezactiveaza comprimarea pentru fi<?>ierul respectiv.

       Ca solu<?>ie alternativa, se poate declan<?>a o rescriere comprimata
       pentru un astfel de fi<?>ier folosind comanda btrfs defrag.
       Re<?>ine<?>i ca, daca fi<?>ierul este accesat din nou prin apelul de
       sistem fallocate, acesta va fi din nou exclus din comprimare pentru
       toate datele noi scrise in el.

DATE INCOMPREHENSIBILE
       Fi<?>ierele care con<?>in date deja comprimate sau date care nu se pot
       comprima eficient din cauza limitarilor de procesor <?>i memorie ale
       implementarilor nucleului utilizeaza o logica de decizie simpla. Daca
       prima por<?>iune de date care urmeaza sa fie comprimata nu este mai
       mica decat originalul, comprimarea intregului fi<?>ier este
       dezactivata. Cu excep<?>ia cazului in care sistemul de fi<?>iere este
       montat cu op<?>iunea compress-force, caz in care btrfs va incerca sa
       comprime fiecare bloc, recurgand la stocarea versiunii necomprimate
       pentru fiecare bloc care ajunge sa fie mai mare dupa comprimare.
       Aceasta nu este o solu<?>ie optima <?>i este supusa optimizarilor <?>i
       dezvoltarii ulterioare.

       Daca un fi<?>ier este identificat ca fiind incompresibil, se activeaza
       un fanion (NOCOMPRESS) <?>i acesta devine persistent ,,sticky". In
       cazul acelui fi<?>ier, comprimarea nu este efectuata decat daca este
       for<?>ata. Fanionul poate fi de asemenea activat prin chattr +m
       (incepand cu e2fsprogs 1.46.2) sau prin proprieta<?>i cu valoarea no
       sau none. O valoare goala il va reini<?>ializa la valoarea implicita
       care este aplicabila in prezent pe sistemul de fi<?>iere montat.

       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 euristici de precomprimare - se efectueaza o evaluare statistica
         rapida a datelor <?>i, in func<?>ie de rezultat, se aplica sau se
         omite comprimarea, bitul NOCOMPRESS nu este activat doar pe baza
         euristicii, ci numai in cazul in care algoritmul de comprimare nu
         aduce o imbunata<?>ire

          $ 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
       Heuristicile au ca scop efectuarea unor teste statistice rapide asupra
       datelor comprimate, pentru a evita o comprimare probabil costisitoare
       care s-ar dovedi ineficienta. Algoritmii de compresie ar putea avea
       <?>i ei o func<?>ie interna de detectare a datelor incompresibile, dar
       acest lucru genereaza un volum suplimentar de opera<?>ii, deoarece
       compresia se efectueaza intr-un alt fir <?>i datele trebuie oricum
       scrise. Heuristica este de tip ,,doar-citire" <?>i poate utiliza
       memoria cache.

       Testele efectuate s-au bazat pe 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 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 cele 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)

              Afi<?>eaza dimensiunea buca<?>ii. Poate fi modificata pentru
              date <?>i metadate (in mod independent) <?>i nu poate fi
              definita pentru tipul de grup de blocuri de sistem. Nu poate fi
              definita pentru dispozitivele impar<?>ite in zone, deoarece
              depinde de dimensiunea fixa a zonei dispozitivului. Limita
              superioara este de 10% din dimensiunea sistemului de fi<?>iere;
              valoarea trebuie sa fie un multiplu de 256 Mio <?>i mai mare
              decat 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.

              Atunci cand se elimina sub-volume mari cu func<?>ia qgroup
              activata, se genereaza o sarcina foarte mare pentru
              contabilitatea qgroup. Daca avem un sub-arbore al carui nivel
              este mai mare sau egal cu aceasta valoare, nu vom declan<?>a
              deloc contabilitatea qgroup, ci vom marca qgroup ca fiind
              inconsistent pentru a evita sarcina de lucru foarte mare.

              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 (incepand cu versiunea 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: pentru a se distinge de cele anterioare, acestea sunt
         fanioane extinse, cu bi<?>i configurabili similari atributelor, dar
         extensibile, iar in viitor vor fi adauga<?>i bi<?>i noi (comenzile
         ioctl sunt FS_IOC_FSGETXATTR <?>i FS_IOC_FSSETXATTR, dar nu au
         legatura cu atributele extinse, denumite <?>i xattrs), nu exista un
         instrument standard pentru a modifica bi<?>ii, exista suport in
         xfs_io(8) <https://man7.org/linux/man-pages/man8/xfs_io.8.html>
         precum comanda xfs_io -c chattr

       Atributele au constrangeri asociate <?>i nu toate combina<?>iile pot fi
       utilizate, ordinea in care sunt definite fiind, de asemenea,
       importanta. Majoritatea atributelor se aplica fi<?>ierelor <?>i
       directoarelor, dar semantica lor poate varia. In cazul directoarelor,
       un atribut poate insemna doar ca acesta se aplica tuturor fi<?>ierelor
       noi (inheritable in lista de mai jos). Unele atribute necesita drepturi
       de administrator pentru a fi definite.

   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)
       Incepand cu versiunea 5.12, btrfs accepta a<?>a-numitul ,,mod de
       impar<?>ire in zone (zoned mode)". Acesta reprezinta un format special
       pe disc <?>i o strategie de alocare/scriere compatibila cu
       dispozitivele impar<?>ire in zone. Pe scurt, un dispozitiv este
       parti<?>ionat in zone de dimensiuni fixe, iar fiecare zona poate fi
       actualizata doar prin adaugare sau poate fi reini<?>ializara. Deoarece
       btrfs nu are structuri de date fixe, cu excep<?>ia super-blocurilor,
       modul de impar<?>ire in zone necesita doar plasarea blocurilor in
       conformitate cu constrangerile dispozitivului. Pute<?>i afla mai multe
       despre intreaga arhitectura la <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
       Dupa cum s-a men<?>ionat mai sus, super-blocul este tratat intr-un mod
       special. Pentru a asigura protec<?>ia impotriva erorilor, cel pu<?>in o
       zona dintr-o loca<?>ie cunoscuta trebuie sa con<?>ina un super-bloc
       valid. Aceasta este implementata sub forma unui tampon circular in doua
       zone consecutive, incepand de la pozi<?>iile cunoscute 0B (0 octe<?>i),
       512 Gio <?>i 4 Tio.

       Valorile sunt diferite fa<?>a de cele de pe dispozitivele fara zone.
       Fiecare super-bloc nou este adaugat la sfar<?>itul zonei; odata ce
       aceasta este completa, zona este reini<?>ializara, iar opera<?>iile de
       scriere continua in urmatoarea zona. Pentru a identifica cel mai recent
       super-bloc, este necesar sa se citeasca pozi<?>iile ambelor zone <?>i
       sa se determine ultima versiune scrisa.

       Spa<?>iul rezervat pentru super-bloc depinde de dimensiunea zonei.
       Copiile secundare <?>i ter<?>iare sunt amplasate la distan<?>e mari,
       intrucat se preconizeaza ca dispozitivele vor avea o capacitate mare,
       de ordinul zecilor de teraocte<?>i. Dimensiunea maxima acceptata a
       zonei este de 8 Gio, ceea ce ar insemna ca, de exemplu, intervalul 0-16
       Gio ar fi rezervat exclusiv pentru super-bloc pe un dispozitiv ipotetic
       cu aceasta dimensiune a zonei. Aceasta reprezinta o risipa, dar este
       necesara pentru a garanta siguran<?>a in caz de colaps.

   Recuperarea zonei, colectarea gunoiului
       Deoarece zonele sunt de tip ,,append-only" -- doar-adaugare,
       suprascrierea datelor sau modificarile COW din metadate fac ca anumite
       par<?>i ale zonelor sa fie utilizate, dar fara a fi conectate la
       structurile sistemului de fi<?>iere. Acest lucru face ca spa<?>iul sa
       devina inutilizabil <?>i sa creasca in timp. Odata ce raportul atinge
       un prag (configurabil), se ini<?>iaza un proces de recuperare in fundal
       care realoca blocurile ramase in uz intr-o zona noua. Zona veche este
       reini<?>ializara <?>i poate fi utilizata din nou.

       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
       Seria WD Ultrastar 600 promoveaza HM-SMR, adica modul de impar<?>ire in
       zone gestionat de gazda. Mai exista inca doua moduri: DA (gestionat de
       dispozitiv, fara exportarea informa<?>iilor de impar<?>ire in zone
       catre sistem) <?>i HA (compatibil cu gazda, poate fi utilizat ca un
       disc obi<?>nuit, dar scrierile zonele impar<?>ite imbunata<?>esc
       performan<?>a). In prezent nu sunt disponibile multe dispozitive, iar
       informa<?>iile despre modul de impar<?>ire in zone, exact sunt greu de
       gasit; verifica<?>i fi<?>ele tehnice sau sursele comunita<?>ii care
       colecteaza informa<?>ii de la dispozitive reale.

       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
       Controlorul null_blk ofera un dispozitiv bazat pe memorie <?>i este
       potrivit pentru testare. Configurarea dispozitivelor prezinta cateva
       particularita<?>i. Modulul trebuie incarcat cu nr_devices=0, altfel
       numerotarea nodurilor de dispozitiv va fi decalata. configfs trebuie
       montat la /sys/kernel/config, iar administrarea dispozitivelor null_blk
       se face in /sys/kernel/config/nullb. Nodurile dispozitivelor sunt
       denumite precum dev/nullb0 <?>i sunt numerotate secven<?>ial. NOTA:
       numele dispozitivului poate fi diferit de numele directorului din
       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

   Emulat: runner (executor) TCMU
       TCMU este un cadru de lucru pentru emularea dispozitivelor SCSI in
       spa<?>iul utilizatorului, oferind diverse sisteme de stocare, precum
       <?>i suport pentru impar<?>irea in zone. Un dispozitiv impar<?>it in
       zone bazat pe fi<?>iere poate oferi mai multe op<?>iuni pentru spa<?>ii
       de stocare <?>i dimensiuni ale zonelor mai mari. Va rugam sa urma<?>i
       instruc<?>iunile de la <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 super-blocul trebuie tratat intr-un mod special; exista tot trei
         copii, dar la distan<?>e diferite (0, 512 Gio, 4 Tio), iar cele doua
         zone consecutive formeaza un tampon inelar al super-blocurilor;
         pentru a gasi pe cel mai recent, este necesar sa-l citim de la
         indicatorul de scriere sau sa efectuam o scanare completa a zonelor

       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)

       Dispozitivul este creat la ini<?>ializarea sistemului de fi<?>iere
       btrfs, fie ca modul, fie ca func<?>ionalitate integrata, <?>i are sens
       doar in acest context. Daca se executa, de exemplu, comanda mkfs fara
       ca modulul sa fie incarcat, dispozitivul nu va fi inregistrat <?>i
       probabil va aparea un mesaj de avertizare in acest sens.

       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

       Dispozitivul de control nu este strict necesar, insa scanarea
       dispozitivelor nu va func<?>iona <?>i va fi necesara utilizarea unei
       solu<?>ii alternative pentru montarea unui sistem de fi<?>iere cu mai
       multe dispozitive. Op<?>iunea de montare dispozitiv poate declan<?>a
       scanarea dispozitivelor in timpul montarii; a se vedea de asemenea
       btrfs device scan.

SISTEM DE FI<?>IERE CU PROFILURI MULTIPLE
       Este posibil ca un sistem de fi<?>iere Btrfs sa con<?>ina mai multe
       profiluri de grupuri de blocuri de acela<?>i tip. Aceasta se poate
       intampla atunci cand o conversie a profilului care utilizeaza filtre de
       echilibrare este intrerupta (a se vedea btrfs-balance(8) <>). Anumite
       comenzi btrfs efectueaza un test pentru a detecta acest tip de
       situa<?>ie <?>i afi<?>eaza un avertisment precum acesta:

          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 exemplul de mai sus, sistemul de fi<?>iere a pornit ca un singur
       dispozitiv cu profilul de grup de blocuri single. Apoi a fost adaugat
       un alt dispozitiv, urmat de o opera<?>ie de echilibrare cu
       convert=raid1, dar, din anumite motive, aceasta nu s-a finalizat.
       Reluarea opera<?>iei de echilibrare cu convert=raid1 va continua <?>i
       va avea ca rezultat un sistem de fi<?>iere in care toate profilurile
       grupurilor de blocuri vor fi RAID1.

       Nota:
          Daca sunte<?>i familiariza<?>i cu filtrele de echilibrare, pute<?>i
          folosi comanda convert=raid1,profiles=single,soft, care va prelua
          doar profilele single neconvertite <?>i le va transforma in raid1.
          Acest lucru poate accelera procesul de conversie, intrucat nu se va
          incerca rescrierea profilelor raid1 deja convertite.

       Este recomandabil sa existe un singur profil, deoarece acesta
       define<?>te in mod clar profilul grupurilor de blocuri nou alocate; in
       caz contrar, acest lucru depinde de politica interna de alocare. Atunci
       cand exista mai multe profiluri, ordinea de selec<?>ie este RAID56,
       RAID10, RAID1, RAID0, cu condi<?>ia ca restric<?>iile privind numarul
       dispozitivelor sa fie respectate.

       Comenzile care afi<?>eaza avertismentul au fost alese astfel incat sa
       atraga aten<?>ia utilizatorului atunci cand starea sistemului de
       fi<?>iere este modificata in acest sens. Acestea sunt: device add,
       device delete, balance cancel, balance pause. Comenzi care afi<?>eaza
       informa<?>ii despre utilizarea spa<?>iului: filesystem df, device
       usage. Comanda filesystem usage afi<?>eaza o linie in rezumatul
       general:

          Multiple profiles:                 yes (data, metadata)

DISPOZITIV DE INSAMAN<?>ARE
       Mecanismul COW <?>i prezen<?>a mai multor dispozitive sub o singura
       carcasa fac posibil un concept interesant, numit ,,dispozitiv de
       ini<?>ializare": extinderea unui sistem de fi<?>iere numai pentru
       citire de pe un dispozitiv cu ajutorul unui alt dispozitiv care preia
       toate opera<?>iile de scriere. De exemplu, imagina<?>i-va o imagine de
       referin<?>a imuabila a unui sistem de operare, completata cu un alt
       dispozitiv care permite utilizarea datelor din imaginea de referin<?>a
       <?>i func<?>ionarea normala. Aceasta idee i<?>i are originea in
       CD-ROM-urile cu sistem de operare de baza, care permiteau utilizarea
       lor pentru sisteme live, dar a devenit invechita. Exista tehnologii
       care ofera func<?>ionalita<?>i similare, precum unionmount <https://en
       .wikipedia.org/wiki/Union_mount>, overlayfs <https://en.wikipedia.org/
       wiki/ OverlayFS> sau instantaneea de imagine qcow2 <https://en
       .wikipedia.org/wiki/Qcow#qcow2>.

       Dispozitivul de insaman<?>are porne<?>te ca un sistem de fi<?>iere
       obi<?>nuit; odata ce con<?>inutul este pregatit, se utilizeaza comanda
       btrfstune -S 1 pentru a-l marca ca dispozitiv de insaman<?>are.
       Montarea unui astfel de dispozitiv nu va permite nicio opera<?>ie de
       scriere, cu excep<?>ia adaugarii unui nou dispozitiv prin comanda btrfs
       device add. Apoi, sistemul de fi<?>iere poate fi remontat in modul de
       citire-scriere.

       Avand in vedere ca sistemul de fi<?>iere de pe dispozitivul de
       insaman<?>are este intotdeauna recunoscut ca fiind doar pentru citire,
       acesta poate fi utilizat pentru a insaman<?>a simultan mai multe
       sisteme de fi<?>iere de pe un singur dispozitiv. UUID-ul asociat in mod
       obi<?>nuit unui dispozitiv este schimbat automat intr-un UUID aleatoriu
       la fiecare montare.

       Nota:
          Inainte de versiunea 6.17 a nucleului, un dispozitiv semanator putea
          fi montat independent, alaturi de sistemele de fi<?>iere create din
          acesta. Insa, incepand cu versiunea 6.17 a nucleului, un dispozitiv
          semanator poate fi montat fie prin intermediul unui sistem de
          fi<?>iere creat din acesta, fie direct ca dispozitiv semanator, dar
          nu in ambele moduri simultan.

          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.

       Odata ce dispozitivul de insaman<?>are este montat, este necesar
       dispozitivul de scriere. Dupa adaugarea acestuia, demontarea <?>i
       remontarea cu comanda umount /ruta; mount /dev/de-scriere /ruta sau
       remontarea in mod citire-scriere cu comanda remount -o remount,rw face
       ca sistemul de fi<?>iere de la /ruta sa fie gata de utilizare.

       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.

       Fanionul dispozitivului de insaman<?>are poate fi dezactivat din nou cu
       comanda  btrfstune -f -S 0, permi<?>and astfel actualizarea cu date mai
       recente; totu<?>i, re<?>ine<?>i ca aceasta opera<?>ie va invalida toate
       sistemele de fi<?>iere existente care utilizeaza acest dispozitiv de
       insaman<?>are. Aceasta procedura este adecvata pentru anumite
       situa<?>ii, dar nu <?>i pentru altele, iar utilizarea fanionului de
       for<?>are in comanda este obligatorie pentru a evita erorile
       accidentale.

       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 Comanda umount /ruta; mount /dev/inscriptibil /ruta poate fi
         inlocuita cu mount -o remount,rw /ruta, dar aceasta nu va elibera
         spa<?>iul sub-volumelor <?>terse pana cand dispozitivul de
         insaman<?>are nu este montat din nou in mod citire-scriere, inainte
         de efectuarea din nou a opera<?>iei de insaman<?>are

   Dispozitive de insaman<?>are in lan<?>
       De<?>i nu este recomandat <?>i reprezinta mai degraba un scenariu de
       utilizare pu<?>in cunoscut <?>i netestat, este posibila conectarea in
       serie a dispozitivelor de insaman<?>are. In primul exemplu,
       dispozitivul inscriptibil /dev/sdb poate fi transformat din nou intr-un
       alt dispozitiv de insaman<?>are, in func<?>ie de dispozitivul de
       insaman<?>are neschimbat /dev/sda. Apoi, folosind /dev/sdb ca
       dispozitiv principal de insaman<?>are, acesta poate fi extins cu un alt
       dispozitiv inscriptibil, sa zicem /dev/sdd, <?>i continua ca mai
       inainte ca o structura simpla arborescenta pe dispozitive.

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

          # btrfstune -S 1 /dev/sda

          # mount /dev/sda /mnt/mnt1
          # btrfs device add /dev/sdb /mnt/mnt1
          # mount -o remount,rw /mnt/mnt1
          ... /mnt/mnt1 este acum 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
       Func<?>ia RAID56 asigura distribuirea datelor <?>i paritatea pe mai
       multe dispozitive, la fel ca in cazul sistemelor tradi<?>ionale
       RAID5/6. Exista insa unele deficien<?>e de implementare <?>i proiectare
       care o fac nesigura in anumite situa<?>ii extreme, iar aceasta
       func<?>ie nu ar trebui utilizata in mediul de produc<?>ie, ci doar in
       scopuri de evaluare sau testare. Protec<?>ia metadatelor in caz de
       intrerupere a alimentarii cu energie electrica nu este garantata 100%
       in cazul RAID56.

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

       Profilele de rezerva ofera acelea<?>i garan<?>ii impotriva pierderii
       unuia sau a doua dispozitive <?>i, in anumite privin<?>e, pot
       reprezenta o imbunata<?>ire. Recuperarea datelor in cazul pierderii
       unui singur dispozitiv va necesita doar accesarea primei sau a celei
       de-a doua copii ramase, care, in general, poate fi stocata pe alte
       dispozitive datorita modului in care func<?>ioneaza RAID1 pe btrfs,
       spre deosebire de un profil de tip ,,striped" (similar cu raid0), care
       ar necesita prezen<?>a tuturor dispozitivelor in permanen<?>a.

       Modelul de alocare a spa<?>iului <?>i consumul difera (de exemplu, pe N
       dispozitive): in cazul raid5, de exemplu, pe fiecare dispozitiv este
       rezervat un bloc de 1 Gio, in timp ce in cazul raid1 fiecare bloc de 1
       Gio este stocat pe doua dispozitive. Consumul fiecarui 1 Gio de
       metadate utilizate este atunci N * 1 Gio fa<?>a de 2 * 1 Gio.
       Utilizarea raid1 este, de asemenea, mai convenabila pentru
       echilibrare/conversie la un alt profil, datorita cerin<?>elor mai
       reduse privind spa<?>iul disponibil pentru blocuri.

   Suport lipsa/incomplet
       Atunci cand RAID56 se afla pe acela<?>i sistem de fi<?>iere cu
       profiluri RAID diferite, raportarea spa<?>iului este inexacta, de
       exemplu df, btrfs filesystem df sau btrfs filesystem usage. Atunci cand
       exista un singur profil pentru fiecare tip de grup de blocuri (de
       exemplu, RAID5 pentru date), raportarea este exacta.

       Atunci cand se porne<?>te procesul de cura<?>are pe un sistem de
       fi<?>iere RAID56, acesta se porne<?>te pe toate dispozitivele, ceea ce
       duce la scaderea performan<?>ei. Solu<?>ia este sa-l porni<?>i separat
       pe fiecare dispozitiv. Din aceasta cauza, statisticile dispozitivelor
       pot sa nu corespunda cu starea reala, iar unele erori pot fi raportate
       de mai multe ori.

       Problema ,,write hole". O oprire necontrolata ar putea lasa o banda
       par<?>ial scrisa intr-o stare in care unele intervale ale benzii <?>i
       paritatea provin din scrierile anterioare, iar altele sunt noi. Nu se
       <?>ine eviden<?>a care informa<?>ii sunt de un fel <?>i care de altul.
       Jurnalul de scriere nu este implementat. O alternativa ar fi un ciclu
       complet de citire-modificare-scriere, care ar asigura scrierea intregii
       benzi, evitand complet problema ,,write hole", dar performan<?>a in
       acest caz s-a dovedit a fi prea slaba pentru a putea fi utilizata.

       Impar<?>irea in benzi se realizeaza pe toate dispozitivele disponibile
       (la momentul alocarii blocurilor), astfel incat, in cazul in care se
       adauga un dispozitiv nou, acesta s-ar putea sa nu fie utilizat imediat
       <?>i ar fi necesara o reechilibrare. Nu este implementata o la<?>ime
       fixa a benzii.

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
              O opera<?>ie care poate fi efectuata asupra unui sistem de
              fi<?>iere Btrfs, de exemplu prin comanda btrfs balance /ruta. O
              opera<?>ie de echilibrare trece din nou toate datele din
              sistemul de fi<?>iere prin alocator. Aceasta are ca scop
              principal reechilibrarea datelor din sistemul de fi<?>iere intre
              dispozitive atunci cand se adauga sau se elimina un dispozitiv.
              O opera<?>ie de echilibrare va regenera copiile lipsa pentru
              nivelurile redundante RAID, in cazul in care un dispozitiv s-a
              defectat. Incepand cu versiunea 3.3 a nucleului Linux, o
              opera<?>ie de echilibrare poate fi facuta selectiva in ceea ce
              prive<?>te par<?>ile sistemului de fi<?>iere care sunt rescrise
              folosind filtre <#man-balance-filters>.

       barrier
              O instruc<?>iune adresata hardware-ului subiacent pentru a se
              asigura ca toate datele situate inaintea barierei sunt scrise
              fizic pe suportul de stocare permanent inaintea celor situate
              dupa aceasta. Se utilizeaza in cadrul abordarii copy on write a
              sistemului de fi<?>iere Btrfs pentru a asigura coeren<?>a
              sistemului de fi<?>iere.

       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
              Unitatea de alocare a spa<?>iului in Btrfs. Un grup de blocuri
              este configurat pe disc de catre alocatorul Btrfs <?>i va consta
              dintr-unul sau mai multe chunks (fragmente), fiecare fiind
              stocat pe un dispozitiv diferit. Numarul de chunks-uri utilizate
              intr-un grup de blocuri va depinde de nivelul sau RAID.

       B-tree Structura fundamentala de stocare a datelor utilizata in btrfs.
              Cu excep<?>ia superblocurilor, toate metadatele btrfs sunt
              stocate intr-unul dintre numero<?>ii arbori-B (B-trees) de pe
              disc. Arborii-B stocheaza perechi cheie/element. De<?>i se
              folose<?>te acela<?>i cod pentru implementarea tuturor
              arborilor-B, exista cateva categorii diferite de arbori-B.
              Denumirea ,,btrfs" se refera la utilizarea arborilor-B.

       btrfsck, fsck, btrfs-check
              Instrument din pachetul btrfs-progs care verifica un sistem de
              fi<?>iere nemontat (offline) <?>i raporteaza eventualele erori
              identificate in structurile sistemului de fi<?>iere. In mod
              implicit, instrumentul ruleaza in modul numai-citire, deoarece
              remedierea erorilor poate fi periculoasa. A se vedea de asemenea
              scrub.

       btrfs-progs
              Instrumente in modul utilizator pentru gestionarea
              func<?>ionalita<?>ilor specifice Btrfs. Gazduite la <http://
              github.com/kdave/btrfs-progs.git>. Interfa<?>a principala pentru
              func<?>iile btrfs este instrumentul independent btrfs, de<?>i
              <?>i alte instrumente, precum mkfs.btrfs <?>i btrfstune, fac
              parte din btrfs-progs.

       chunk  O parte a unui block group. 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
              Termenul este folosit de obicei in contextul subvolumelor
              <?>terse. Este vorba despre un proces care ruleaza in fundal
              <?>i care elimina datele propriu-zise odata ce un subvolum a
              fost <?>ters. Procesul de cura<?>are poate implica o activitate
              intensa la nivel de opera<?>ii de In/Ie<?> <?>i CPU, in
              func<?>ie de gradul de fragmentare <?>i de cantitatea de date
              partajate cu alte subvolume.

              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
              Cunoscuta <?>i sub denumirea de COW. Metoda utilizata de btrfs
              pentru modificarea datelor. In loc sa suprascrie direct datele
              in loca<?>ia ini<?>iala, btrfs realizeaza o copie a datelor, o
              modifica <?>i apoi scrie datele modificate intr-o alta loca<?>ie
              (neutilizata) de pe disc. Apoi actualizeaza metadatele pentru a
              reflecta noua loca<?>ie a datelor. Pentru a actualiza
              metadatele, blocurile de metadate afectate sunt tratate in
              acela<?>i mod. In sistemele de fi<?>iere COW, fi<?>ierele tind
              sa se fragmenteze pe masura ce sunt modificate. Metoda
              copy-on-write este utilizata <?>i in implementarea snapshots
              <?>i reflink copies. Un sistem de fi<?>iere copy-on-write este,
              in teorie, intotdeauna consistent, cu condi<?>ia ca hardware-ul
              subiacent sa accepte 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.1                          20 martie 2026                        BTRFS(5)