Fedora pensa a BTRFS come default (per laptop e workstation)

Ogni tanto BTRFS fa capolino nelle discussioni su Linux, e forse per gli stessi motivi di fondo che fanno parlare di systemd: c’è una nutrita schiera di sostenitori, contrapposta ad un’altrettanto ben nutrita schiera di critici.

Alcune distribuzioni, come openSUSE, sono tra i sostenitori più diretti. Altre, come Ubuntu, cercano soluzioni alternative – come ZFS on Linux.
Anche Red Hat non ama molto BTRFS, tanto da averlo ufficialmente deprecato – in favore del proprio filesystem di nuova generazione, Stratis.

Ma le due fazioni non si incarnano solo nello scontro da distribuzioni: all’interno di ogni progetto, anche gli sviluppatori si dividono su fronti opposti – ovviamente.
Quindi, sebbene la situazione sia del tutto normale, fa comunque una certa impressione vedere Fedora aprire una discussione al suo interno.

Già, perché pur essendo più o meno ufficialmente la base per lo sviluppo di Red Hat, Fedora ancora non ha buttato via BTRFS. E alcuni suoi sviluppatori hanno ben pensato di usarlo, di default, anche se solo per workstation e/o laptop.
La proposta è molto articolata nella disamina di vantaggi e svantaggi, che comprendono un uso più efficiente (e facile, per l’utente) dello spazio disco, nonché i rollback, utili in installazioni fallite o come backup automatico.
Ricordiamo anche che Stratis è tutt’ora in sviluppo, mentre BTRFS è (nel bene o nel male) parte del Kernel da più di 10 anni: sicuramente più usabile.

Insomma, una proposta ragionata e pensata, ma che apre un fronte interno a Red Hat: alternativa o provocazione?

Ho coltivato la mia passione per l’informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.

19 risposte a “Fedora pensa a BTRFS come default (per laptop e workstation)”

  1. Avatar JustATiredMan
    JustATiredMan

    Personalmente quando ho storage in produzione, non ho mai avuto necessita’ di rimpicciolire un volume… e pero’ vero il contrario.
    BTRFS poi non e’ assolutamente a livello di ZFS ne come affidabilita’ ne come prestazioni (intese non solo come performances pure, ma come features) e poi di btrfs non ho mai capito perche’ uno snapshot debba essere pure scrivibile…. Sono 10 anni ormai che btrfs continua a portarsi dietro problemi piu’ o meno piccoli (sempre che non essere affidabile sui raid 5 e 6 sia piccolo come problema), che ancora oggi non sono risolti… forse e’ meglio cercare di puntare piu su openzfs, anche se capisco le remore di Torvalds in termini di licenza… quando si ha che fare con Oracle bisogna sempre andare con i piedi di piombo.

  2. Avatar Simone Picciau
    Simone Picciau

    Grazie mille per le spiegazioni!

  3. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Si certo. Mah… Puoi commentare qui da solo su un blog, senza avere delle risposte più tecniche che ti farebbero imbarazzare.
    Ma basta un appassionato con la curiosità che si documenta, che dici molte inesattezze ed è palesemente visibile che non lo usi e che sei un hater.

  4. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Altra tua perla…

    Inoltre non venne mai definito (e non lo è tuttora) un formato del file system, quindi spesso capitava che con un aggiornamento del kernel il file system cambiasse automaticamente formato al primo mount e diventasse inusabile in caso di rollback.

    È dichiarato stabile!
    Anche su queste banalità…

    On-disk format
    The filesystem disk format is stable. This means it is not expected to change unless there are very strong reasons to do so. If there is a format change, filesystems which implement the previous disk format will continue to be mountable and usable by newer kernels.

    The core of the on-disk format that comprises building blocks of the filesystem:

    layout of the main data structures, eg. superblock, b-tree nodes, b-tree keys, block headers
    the COW mechanism, based on the original design of Ohad Rodeh’s paper “Shadowing and clones”
    Newly introduced features build on top of the above and could add specific structures. If a backward compatibility is not possible to maintain, a bit in the filesystem superblock denotes that and the level of incompatibility (full, read-only mount possible).

    Ah no!, scusa da te, solo da te, non è stabile. 🙂 Quindi se lo dici tu, non lo è. Scusa…

  5. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Inoltre hanno assunto Chris Mason e altri ingegneri, quindi in caso di problemi mettono mano direttamente al kernel e mandano patch in upstream.

    This work, Bacik said, was done by the infrastructure team without any sort of encouragement by Facebook’s Btrfs developers; indeed, they didn’t even know that it was happening. He was surprised by how well it worked in the end.

  6. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Non puoi farlo a livello di subvolume. Puoi farlo a livello dell’oggetto rappresentato dal subvolume, ovvero la directory.

    Il risultato finale non cambia, hai sempre un intero subvolume con diverso flag rispetto ad altri.

    E tra l’altro la differenza è che il primo caso è come Btrfs era stato pensato ma non si è riuscito ad implementare.
    Il secondo è un workaround al primo e che opera ad un livello superiore a quello originale.

    È previsto ma non ancora implementato, ma alla fine lo faranno. Almeno cosi hanno detto più volte. Cioè opzioni di mount diversi per subvolumi.

  7. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Qui hai ragione.
    Ma qualsiasi azienda non spende risorse su qualcosa che non funziona, ma su qualcosa che gli risolve i problemi invece che crearli. Josef ha risposte più volte a queste insinuazioni.
    Se Btrfs fosse rotto o non funzionasse bene, non lo avrebbero usato.

  8. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Anzi, stanno valutando di usare Btrfs anche su WhatsAPP:

    An in-progress project concerns the WhatsApp service. WhatsApp messages are normally stored on the users’ devices, but they must be kept centrally when the user is offline. Given the number of users, that’s a fair amount of storage. Facebook is using XFS for this task, but has run into unspecified “weird scalability issues”. Btrfs compression can help here as well, and snapshots will be useful for cleaning things up.

  9. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    workaround Che funziona e che fa quel che vuoi, quindi non penso sia una priorità.

  10. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Cosa ti cambia, una volta creato un subvolume, o tramite script (installer) o manualmente, invece di inserire l’opzione di mount, dare un comando?
    L’unico CONTRO che vedo, è che al comando “mount -t btrfs” vedi le opzioni di mount globali, non vedi che il subvolume X ha settato altro algoritmo di compressione, ma vede quello globale.

  11. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Si, ripeto, workaround che è banale e viene settato permanente, quindi al umount e mount lo hai sempre settato e visibile:

    manu@desktop:~$ sudo btrfs subvolume create /home/emanu/cartellaX
    Create subvolume ‘/home/emanu/cartellaX’

    emanu@desktop:~$ sudo btrfs property set /home/emanu/cartellaX compression lzo

    emanu@desktop:~$ sudo btrfs property get /home/emanu/cartellaX
    ro=false
    compression=lzo

    emanu@desktop:~$ sudo btrfs subvolume list / | grep cartellaX
    ID 895 gen 789247 top level 257 path @home/emanu/cartellaX

    Io ho tutto in zstd livello 1 o 3

    emanu@desktop:~$ mount -t btrfs
    /dev/sda2 on / type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=256,subvol=/@)
    /dev/sda2 on /home type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=257,subvol=/@home)
    /dev/sda2 on /opt type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=258,subvol=/@opt)
    /dev/sda2 on /root type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=259,subvol=/@root)
    /dev/sda2 on /tmp type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=261,subvol=/@tmp)
    /dev/sda2 on /usr/local type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=262,subvol=/@usrlocal)
    /dev/sda2 on /var/crash type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=265,subvol=/@varcrash)
    /dev/sda2 on /var/cache type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=264,subvol=/@varcache)
    /dev/sda2 on /var/backups type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=263,subvol=/@varbackups)
    /dev/sda2 on /var/games type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=266,subvol=/@vargames)
    /dev/sda2 on /var/lib/flatpak type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=268,subvol=/@varlibflatpak)
    /dev/sda2 on /var/lib/AccountsService type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=267,subvol=/@varlibacc)
    /dev/sda2 on /var/log type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=270,subvol=/@varlog)
    /dev/sda2 on /var/lib/libvirt type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=269,subvol=/@varlibvirt)
    /dev/sda2 on /var/mail type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=271,subvol=/@varmail)
    /dev/sda2 on /var/tmp type btrfs (rw,noatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=272,subvol=/@vartmp)
    /dev/sdb1 on /media/emanu/dati/game type btrfs (rw,noatime,compress=zstd:3,space_cache=v2,autodefrag,subvolid=1435,subvol=/@game)
    /dev/sdb1 on /media/emanu/dati/dati type btrfs (rw,noatime,compress=zstd:3,space_cache=v2,autodefrag,subvolid=1411,subvol=/@dati)
    /dev/sda2 on /run/timeshift/backup type btrfs (rw,relatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=5,subvol=/)
    /dev/sda2 on /mnt/rmbtrfs type btrfs (rw,relatime,compress=zstd:1,ssd,space_cache=v2,autodefrag,subvolid=5,subvol=/)

  12. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Continui a criticare un filesystem che non conosci e che non ne segui lo sviluppo.
    1) Puoi settare la compressione per file, cartella o subvolume.
    2) Puoi settare il “nocow” per file cartella o subvolume”, puoi anche disabilitare la compressione.
    3) Il fatto che ti permetta di creare snapshot RW, non vedo perché sia uno svantaggio, hai la possibilità in base alle tue esigenze di farlo RW o RO, per poter scrivere o ripristinare uno snapshot, sta all’utente fare la cosa giusta in base alla sua esigenza.
    4) “autodefrag” non rompe i riferimenti agli snapshot e c’è una patch per averlo a livello di file, cartella o subvolume.
    Cosa manca dai flag per opzioni su cartella, file o subvolume?
    5) Visto che sei cosi esperto di filesystem e dai degli ignoranti agli sviluppatori di Btrfs, mi piacerebbe che questa critica, se la ritieni costruttiva e valida, la pubblicassi sulla maiiling list o su Reddit dove ci sono sviluppatori di Btrfs e non su un blog dove te la canti e te la suoni da solo.
    Ripeto per l’ennesima volta, vatti a leggere il caso d’uso su come Facebook usa Btrfs, ti basta leggere la mailing list di Fedora.
    Poi mi spieghi come cambi al volo i livelli raid con ZFS, senza andare offline.
    È bello leggervi “Btrfs rotto di design” o “Btrfs progettato senza uno scopo”, immagino che siete esperti, ingegneri di fama internazionale sul filesystem.
    Ripeto, mi piacerebbe vedervi discutere con chi può rispondervi punto per punto, e se vuoi puoi farlo, aspetto.

  13. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Perché uno snapshot puoi avviarlo come sistema, che poi non è altro che un subvolume…
    snapshot 1 > OS Arch
    snapshot 2 > OS Ubuntu
    scegli tu all’avvio.
    Se usi send o li vuoi RO, c’è l’opzione.
    Non vedo perché criticate una funzionalità in più, è la prima volta che leggo una critica sulla possibilità di avere snapshot RW…
    E ci perdo molto del mio tempo libero a documentarmi e leggere discussioni sul filesystem.
    Poi leggo i commenti di alcuni su blog, e mi cadono le braccia…

    <toplevel (volume root directory)
    +-- root (subvolume root directory, mounted at /)
    | +-- bin (directory)
    | +-- usr (directory)
    +-- root_snapshot_2015-01-01 (root directory of snapshot of subvolume "root")
    | +-- bin (directory)
    | +-- usr (directory)
    +-- root_snapshot_2015-06-01 (root directory of snapshot of subvolume "root")
    | +-- bin (directory)
    | +-- usr (directory)
    +-- home (subvolume root directory, mounted at /home)
    +-- home_snapshot_2015-01-01 (root directory of snapshot of subvolume "home")
    +-- home_snapshot_2015-12-01 (root directory of snapshot of subvolume "home")

  14. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Nel tempo, ti incollo la risposta del manutentore di Btrfs:

    “No amount of money or additional manpower can make up for bad design.”

    Talking about the bad design, can you please point to something concrete? This is said a lot in comments but I’d really like to know what exactly is meant. The only thing I know about is the report from E. Shishkin, that’s been found to be an implementation bug not a design flaw.

    “Btrfs was a classic case of starting coding before the design was finalised …”

    That’s not true. The design had been on paper before any code was written, published as https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.161.6863 “B-trees, Shadowing, and Clones” by Ohad Rodeh.

    What is being fixed, like in any complex piece of software, are coding errors and logic bugs.

  15. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Non mi risulta affatto, considerando che la compressione per subvolume è broken.
    h t t p s : / / btrfs . wiki . kernel . org /index . php/ Compression#Can_I_set_compression_per-subvolume . 3F

    Ecco perché ti dico che critichi un filesystem che non conosci, non puoi settarlo come opzione di mount ma puoi settarlo, come ti ho scritto a livello di file, cartella e subvolume, quando e come vuoi, è un settaggio permanente, non c’è bisogno dell’opzione di mount.
    Posso settare comrpess un intero subvolume, solo una cartella o solo un file, se ho l’intero subvolume con l’opzione di mount “compress”, posso in una specifica cartella disabilitare o scegliere un diverso algoritmo di compressione.
    Cerca che trovi. Documentati, cerca btrfs property.

    Il nocow è un attributo sull’inode, non una mount option del file system.
    Se invece intendi nodatacow, mi spiace ma vale LO STESSO discorso della compressione.
    Tre subvolumi in uno stesso pool vengono montati TUTTI con le STESSE opzioni di mount, e non è possibile fare diversamente, perché i subvolumi NON SONO device, ma directory con un SUBVOLID.

    Stessa cosa del compress, setto il subvolume della swap “nocow” per lo swapfile, tutto all’interno del subvolume sarà “nocow”. Ovviamente è valido per i nuovi file, o lo setti prima di copiarci i file, anche qui non hai bisogno dell’opzione di mount nodatacow ed è permanente. C’è una patch su libvirt che lo setta in automatico quando crei immagini e sei su Btrfs. Quindi anche qui puoi avere un intero subvolume “nocow” senza opzione di mount.

    Nella tua idea immaginaria, sicuro. Nella realtà meno.

    Nella realtà, ripeto, documentati. Quello che rompe i ref è il defrag manuale e ricorsivo “sudo btrfs fi defragment …“, anche qui hai bisogno di documentazione o di usarlo.

    Diciamo che il mio vero nome lo conoscono in diversi vendor, di questo posso essere soddisfatto. Il tuo non credo.

    Sinceramente non mi interessa, buon per te. Ma vedo una tua ignoranza o forse sei solo un hater, verso Btrfs. E questo è triste visto che sei un informatico.
    Visto che sei cosi famoso, ripeto, aspetto una tua discussione, su punti tecnici su Btrfs, IRC (#btrfs freenode), reddit, mailing list. Ti aspetto, fammi sapere quando e dove 🙂
    A parte tutto, hai mai usato Btrfs negli ultimi anni? Sembra di no.

  16. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    APPUNTO! il subvolume è una directory, anche se realmente non lo è, puoi IMPOSTARE un intero subvolume compress, nocow o altro algoritmo di compressione!
    QUINDI, si, puoi impostare un intero subvolume con i flag descritti sopra!
    Quindi se crei il subvolume PIPPO:
    sudo btrfs subvolume create /@pippo

    sudo btrfs property set /@pippo compress zlib/lzo/zstd/none

    Ed hai un intero subvolume compresso o non compresso.
    openSUSE mette il “nocow” sul suo subvolume /var.
    Quindi puoi scavalcare le limitazioni ad oggi che non puoi farlo per opzione di mount, ma hai lo stesso effetto.
    Ad oggi c’è il limite che non puoi scegliere il livello di compressione su ZSTD e ZLIB, ma c’è una patch e a breve sarà possibile.

  17. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Ma ZFS non è Btrfs, perché li confronti continuamente? hanno dei PRO e contro entrambi.
    Tu hai detto che non puoi abilitare la compressione su un intero subvolume, e io ti ho risposto che puoi farlo, l’importante è avere il risultato di diversificare le varie opzioni sui vari subvolumi e che li puoi gestire come vuoi.
    Questo dimostra che posso gestire in maniera indipendente i subvolumi, per molti aspetti: compress, nocompress, compress=alg, nocow, autodefrag (a breve).
    Ad ognuno di questo subvolume posso cambiare la compressione, come vedi alcuni sono “NOCOW” e sono subvolumi separati toplevel, ma posso impostarli anche su quelli nested.

    $ sudo lsattr /mnt/rmbtrfs/
    ——————– /mnt/rmbtrfs/@
    ——————– /mnt/rmbtrfs/@home
    ——————– /mnt/rmbtrfs/@opt
    ——————– /mnt/rmbtrfs/@root
    —————C—- /mnt/rmbtrfs/@tmp
    ——————– /mnt/rmbtrfs/@usrlocal
    ——————– /mnt/rmbtrfs/@varbackups
    —————C—- /mnt/rmbtrfs/@varcache
    —————C—- /mnt/rmbtrfs/@varcrash
    —————C—- /mnt/rmbtrfs/@vargames
    ——————– /mnt/rmbtrfs/@varlibacc
    ——————– /mnt/rmbtrfs/@varlibflatpak
    —————C—- /mnt/rmbtrfs/@varlibvirt
    —————C—- /mnt/rmbtrfs/@varlog
    —————C—- /mnt/rmbtrfs/@varmail
    —————C—- /mnt/rmbtrfs/@vartmp
    ——————– /mnt/rmbtrfs/timeshift-btrfs

  18. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Perché il secondo è nato come replacement del primo su Linux. E soprattutto è nato con la pretesa di fare meglio, salvo fallire clamorosamente.

    Prevedi il futuro? Magari hai ragione tu o magari tra qualche anno avrai torto. Vedremo.

    No, io ho detto che non gestisce le mount option per subvolume e ho fatto l’esempio della compressione.

    E io ti ho risposto che se non puoi farlo a livello di mount, puoi farlo a livello di subvolume, cartella o file, senza specificarlo al mount, il risultato è che hai quel che vuoi sull’intero volume senza opzione di mount.
    Quindi:
    posso impostare la compressione/nocow… per opzione di mount su un subvolume? No
    posso impostare la compressione/nocow… per subvolume? Si
    In un certo senso stai gestendo un subvolume separatamente perché ottieni quello che vuoi e per i tuoi casi d’uso.
    Vuoi comprimere sulla radice in lzo e sulla home in zstd?
    sudo btrfs property set /mnt/@ compress=lzo

    sudo btrfs property set /mnt/@home compress=zstd

    A breve anche il livello di compress.
    Hai una cartella sulla home dove non ha senso comprimere?
    sudo btrfs sub create /home/utente/cartellaX

    sudo btrfs property set /home/utente/cartellaX compress none

    In questo caso lo escludi anche se fai snapshot sulla home, gli snap non sono ricorsivi e se vuoi puoi inviarlo con send: snapshot RO, send.

  19. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Si, ripeto, qui hai ragione, di certo Facebook non è l’azienda di Pippo.
    Anche grazie al caso d’uso di Facebook che Btrfs si è stabilizzato ed ha risolto molti bug.
    La prenotazione dello spazio, la nuova cache che presto sarà di default, è tutta opera di Facebook, sempre grazie ai loro casi d’uso.
    Questo caso d’uso cosi enorme sullo storage, di certo migliora lo sviluppo del filesystem, quindi è un vantaggio per Btrfs, e non è banale avere un caso d’uso come Facebook.

    Btrfs lead developer Chris Mason explained that this forthcoming free space cache is tree-based and is faster with less overall work for updating as the commit progresses.

    Development on this free space tree was led by Omar Sandoval, a computer engineering student that was interning at Facebook over the summer. This space cache is being redone as Facebook found that for large file-systems the free space caching code was taking a long time during commits. Fortunately, most users won’t see these current limitations as the slowdowns were reported for file-systems of around 30+ Terabytes.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *