Parliamo di Btrfs

[emanuc]

Parliamo del moderno filesystem COW incluso nel kernel Linux: Btrfs.
Curiosità, trucchi, aggiornamenti e motivi per cui usare btrfs rispetto ad altri filesystem Linux.
Documentazione Ufficiale: https://btrfs.readthedocs.io/en/latest/

[emanuc]

Gli ultimi aggiornamenti nel kernel 6.10 sono semplici pulizie e miglioramenti alle prestazioni, miglioramenti alle prestazioni che sono una costante ad ogni "GIT PULLl"
https://lore.kernel.org/linux-kernel/32 ... gmx.com/T/

[emanuc]

Per visualizzare alcune funzionalità da abilitare al mkfs:

Codice: Seleziona tutto

sudo mkfs.btrfs -O list-all

Ad oggi:

Codice: Seleziona tutto

sudo mkfs.btrfs -O list-all
Filesystem features available:
mixed-bg            - mixed data and metadata block groups (compat=2.6.37, safe=2.6.37)
quota               - hierarchical quota group support (qgroups) (compat=3.4)
extref              - increased hardlink limit per file to 65536 (compat=3.7, safe=3.12, default=3.12)
raid56              - raid56 extended format (compat=3.9)
skinny-metadata     - reduced-size metadata extent refs (compat=3.10, safe=3.18, default=3.18)
no-holes            - no explicit hole extents for files (compat=3.14, safe=4.0, default=5.15)
fst                 - free-space-tree alias
free-space-tree     - free space tree, improved space tracking (space_cache=v2) (compat=4.5, safe=4.9, default=5.15)
raid1c34            - RAID1 with 3 or 4 copies (compat=5.5)
zoned               - support zoned (SMR/ZBC/ZNS) devices (compat=5.12)
bgt                 - block-group-tree alias
block-group-tree    - block group tree, more efficient block group tracking to reduce mount time (compat=6.1)
rst                 - raid-stripe-tree alias
raid-stripe-tree    - raid stripe tree, enhanced file extent tracking (compat=6.7)
squota              - squota support (simple accounting qgroups) (compat=6.7)

Nota sul kernel 5.15:

mkfs: new defaults!
no-holes
free-space-tree
DUP for metadata unconditionally

Nota su DUP: Nei kernel precedenti al 5.15, il "DUP" sui metadati non era abilitato di default sui dischi a stato solido.
La motivazione che ha spinto gli sviluppatori ad abilitarlo di default anche sui dischi a stato solido: https://github.com/kdave/btrfs-progs/is ... -739423260

Funzionalità che abilito ad ogni "mkfs" su Btrfs:

Codice: Seleziona tutto

sudo mkfs.btrfs --csum xxhash -O block-group-tree /device

Spiegazione:
- xxhash: è un algoritmo moderno e più robusto, inoltre sul mio hardware è più veloce rispetto a crc32c che è il default.

- block-group-tree: Rende il mount molto più veloce, fa la differenza su un filesystem con oltre 1TB di spazio occupato. È parte del lavoro "Extent tree v2 ". È una funzionalità incompatibile, versione del kernel 6.1.

Benchmark sull'abilitazione di "block-group-tree" preso da un utente su Reddit:

# time mount -v /mnt/Backup
mount: /dev/sde mounted on /mnt/Backup.

real 0m25.962s
user 0m0.006s
sys 0m0.282s

# time mount -v /mnt/Backup
mount: /dev/sde mounted on /mnt/Backup.

real 0m0.610s
user 0m0.005s
sys 0m0.019s

EDIT: Un'altra funzionalità che abilito, se la distro che uso non lo fa di default, è la compressione zstd.
Sul disco dal gaming (Steam) dove ho tanti giochi, mi permette di risparmiare un circa 300gb di dati, con l'opzione: "compress-force=zstd:1"


Sul disco di sistema dove ho l'opzione: "compress=zstd:1"

È sul subvolume flatpak che ho ottenuto il maggior guadagno di spazio.: 30G > 7.9G

[saxtro]

Io utilizzo una strategia diversa.

Utilizzo btrfs solo per il sistema. Per la /home di solito utilizzo XFS, preferisco comunque un filesystem classico.
Nella /home faccio uso intenso di macchine virtuali e preferisco evitare qualsiasi effetto collaterale legato a snapshot, e operazioni CoW su files con modifiche frequenti.
Per il backup della /home utilizzo duplicacy sulle sottodirectory di interesse.

Il filesystem btrfs lo utilizzo con le impostazioni di default, al momento non ho mai avuto necessità di effettuare tuning sui parametri di mount. (Lo farei solo per risolvere problemi di performance)

Anche la compressione, la utilizzerei solo se fosse impostata di default, lascerei comunque il crc32, più performante con il mio processore (a parità di operazione, meno cicli CPU e I/O più elevato)



Di solito "cifro" solo la /home e mai la /.
Quando FSCRYPT per btrfs, sarà stabile e consigliata, probabilmente la proverò. (https://lwn.net/ml/linux-btrfs/cover.17 ... panda.com/)
(e potrei creare /home in btrfs, utilizzando la partizione dedicata solo per le virtual machines e non per tutta la /home)

[korda]

Io utilizzo una strategia diversa.

Utilizzo btrfs solo per il sistema. Per la /home di solito utilizzo XFS, preferisco comunque un filesystem classico.
Nella /home faccio uso intenso di macchine virtuali e preferisco evitare qualsiasi effetto collaterale legato a snapshot, e operazioni CoW su files con modifiche frequenti.
Per il backup della /home utilizzo duplicacy sulle sottodirectory di interesse.

Il filesystem btrfs lo utilizzo con le impostazioni di default, al momento non ho mai avuto necessità di effettuare tuning sui parametri di mount. (Lo farei solo per risolvere problemi di performance)

Anche la compressione, la utilizzerei solo se fosse impostata di default, lascerei comunque il crc32, più performante con il mio processore (a parità di operazione, meno cicli CPU e I/O più elevato)



Di solito "cifro" solo la /home e mai la /.
Quando FSCRYPT per btrfs, sarà stabile e consigliata, probabilmente la proverò. (https://lwn.net/ml/linux-btrfs/cover.17 ... panda.com/)
(e potrei creare /home in btrfs, utilizzando la partizione dedicata solo per le virtual machines e non per tutta la /home)

Questa è esattamente la mia problematica: per avere performance decenti sulle vm ho dovuto rimuovere quote, togliere flag autodefrag, rimuovere in ogni caso @home da qualsiasi snapshot (in alternativa la backuppo a parte via Borg, ma non sono completamente soddisfatto di ciò)

[emanuc]

Anche la compressione, la utilizzerei solo se fosse impostata di default, lascerei comunque il crc32, più performante con il mio processore (a parità di operazione, meno cicli CPU e I/O più elevato)

Curiosità: Che CPU hai? Io ho un Ryzen 5 2600X

Di solito "cifro" solo la /home e mai la /.
Quando FSCRYPT per btrfs, sarà stabile e consigliata, probabilmente la proverò. (https://lwn.net/ml/linux-btrfs/cover.17 ... panda.com/)
(e potrei creare /home in btrfs, utilizzando la partizione dedicata solo per le virtual machines e non per tutta la /home)

FSCrypt su Btrfs non è ancora stato unito, è in ritardo perché all'interno di meta non sono più interessati a quel caso d'uso, quindi hanno dato una priorità bassa per lo sviluppo. Quindi passerà tempo.
Le impostazioni di default non sono sempre la scelta migliore, basta saper quel che si fa per scegliere le opzioni di mount più sensate per il proprio caso d'uso.

[emanuc]

Questa è esattamente la mia problematica: per avere performance decenti sulle vm ho dovuto rimuovere quote, togliere flag autodefrag, rimuovere in ogni caso @home da qualsiasi snapshot (in alternativa la backuppo a parte via Borg, ma non sono completamente soddisfatto di ciò)

Questo è il motivo per cui qualsiasi distro che supporta i subvolumi su Btrfs crea il subvolume "home". Se non hai esigenze particolari, come ad esempio poter ripristinare una modifica o un'eliminazione accidentale di un file (macOS e Windows fanno qualcosa del genere), la scelta migliore è non includerlo nel regime degli snapshot.
Per le VM, evita ovviamente le immagini 'COW' e scegli le immagini 'RAW', poiché COW su COW è la peggiore situazione in termini di performance.
Se usi molto le VM, "autodefrag" non è l'opzione ideale, ma crea un timer per deframmentare solo le immagini.
Se vuoi usare gli snapshot sulla home, la mia raccomandazione è di creare una pianificazione che mantenga gli snapshot per un massimo di una settimana e non più di 20 snapshot. Per evitare che gli snapshot occupano troppo spazio, visto che sulla home ci sono frequenti modifiche ai file. Inoltre ricorda che gli snapshot non sono backup.
Il problema delle performance con molti snap e quota sarà risolto con il cambio di formato sul disco.

[saxtro]

...
Curiosità: Che CPU hai? Io ho un Ryzen 5 2600X

è sempre un Ryzen, Ryzen 9 7950X

...
Le impostazioni di default non sono sempre la scelta migliore, basta saper quel che si fa per scegliere le opzioni di mount più sensate per il proprio caso d'uso.

Vero, molto dipende da hardware e configurazioni in uso. Credo sia anche corretto scrivere che i valori di default di solito sono i più testati.

Ad esempio con il processore sopra riportato (non ho testato), credo potrei utilizzare un algoritmo di compressione qualunque con un rapporto di compressione alto.
Potrei ottenere degli I/O inverosimili, però non ho mai abilitato compressione perchè io ho il pallino per tenere le temperature il più basse possibile (ergo non sottrarre parti % di idle a favore di system)

[emanuc]

...
Curiosità: Che CPU hai? Io ho un Ryzen 5 2600X

è sempre un Ryzen, Ryzen 9 7950X

...
Le impostazioni di default non sono sempre la scelta migliore, basta saper quel che si fa per scegliere le opzioni di mount più sensate per il proprio caso d'uso.

Vero, molto dipende da hardware e configurazioni in uso. Credo sia anche corretto scrivere che i valori di default di solito sono i più testati.

Ad esempio con il processore sopra riportato (non ho testato), credo potrei utilizzare un algoritmo di compressione qualunque con un rapporto di compressione alto.
Potrei ottenere degli I/O inverosimili, però non ho mai abilitato compressione perchè io ho il pallino per tenere le temperature il più basse possibile (ergo non sottrarre parti % di idle a favore di system)

Strano, stessa famiglia di CPU con risultati diversi.
Sì, le impostazioni di default sono generalmente le più testate, ma ci sono delle eccezioni. Ad esempio, "block-group-tree" è una funzione recente e non può essere il default perché ci sono ancora dei kernel LTS incompatibili.
Un'altra eccezione secondo me è la compressione: sulle CPU moderne può essere abilitata ad occhi chiusi.
Con una CPU come la tua ha senso un algoritmo più alto se usi un disco meccanico, diversamente l'unico motivo per farlo è perché si vuole risparmiare spazio.

[emanuc]

Comunque, "xxhash" l'ho scelto non solo per la velocità sul mio hardwrae rispetto a crc32c, ma perché è un hash più robusto.
Consiglio questa lettura sulla proposta di renderlo di default su Btrfs: https://github.com/kdave/btrfs-progs/issues/548

[korda]

Questa è esattamente la mia problematica: per avere performance decenti sulle vm ho dovuto rimuovere quote, togliere flag autodefrag, rimuovere in ogni caso @home da qualsiasi snapshot (in alternativa la backuppo a parte via Borg, ma non sono completamente soddisfatto di ciò)

Questo è il motivo per cui qualsiasi distro che supporta i subvolumi su Btrfs crea il subvolume "home". Se non hai esigenze particolari, come ad esempio poter ripristinare una modifica o un'eliminazione accidentale di un file (macOS e Windows fanno qualcosa del genere), la scelta migliore è non includerlo nel regime degli snapshot.
Per le VM, evita ovviamente le immagini 'COW' e scegli le immagini 'RAW', poiché COW su COW è la peggiore situazione in termini di performance.
Se usi molto le VM, "autodefrag" non è l'opzione ideale, ma crea un timer per deframmentare solo le immagini.
Se vuoi usare gli snapshot sulla home, la mia raccomandazione è di creare una pianificazione che mantenga gli snapshot per un massimo di una settimana e non più di 20 snapshot. Per evitare che gli snapshot occupano troppo spazio, visto che sulla home ci sono frequenti modifiche ai file. Inoltre ricorda che gli snapshot non sono backup.
Il problema delle performance con molti snap e quota sarà risolto con il cambio di formato sul disco.

Rimane un dubbio però...

Se escludessi @home dagli snapshot, causa dischi virtuali delle vm, escluderei dagli snapshot anche le installazioni snap (non stanno mica nella home o sbaglio?)

[woddy68]

Personalmente utilizzo Btrfs da anni, ma non ho mai pensato agli snapshot come backup dati, quindi capisco la scelta di molte distro di non includere la /home negli snapshot.
Nessuno vieta di farlo, ma secondo me sarebbe meglio un classico backup.
Tra l'altro nella /home ci stanno tutte le configurazioni delle applicazioni e non solo, non credo sia una buona idea includerli, senza contare il fatto che questo richiederebbe anche molto più spazio.
La logica degli snapshot di sistema è quello di preservare il sistema dopo una modifica, in modo da ripristinarlo facilmente se qualcosa andasse storto, quindi ad ogni modifica di sistema dovrebbe corrispondere uno snapshot.
Questo è quello che avviene ad es. in openSUSE ma immagino anche in altre distribuzione, ogni volta che si apportano modifiche al sistema installando o rimuovendo software o anche solo modificando un parametro, viene scattata una istantanea pre e post.

[korda]

Personalmente utilizzo Btrfs da anni, ma non ho mai pensato agli snapshot come backup dati, quindi capisco la scelta di molte distro di non includere la /home negli snapshot.
Nessuno vieta di farlo, ma secondo me sarebbe meglio un classico backup.
Tra l'altro nella /home ci stanno tutte le configurazioni delle applicazioni e non solo, non credo sia una buona idea includerli, senza contare il fatto che questo richiederebbe anche molto più spazio.
La logica degli snapshot di sistema è quello di preservare il sistema dopo una modifica, in modo da ripristinarlo facilmente se qualcosa andasse storto, quindi ad ogni modifica di sistema dovrebbe corrispondere uno snapshot.
Questo è quello che avviene ad es. in openSUSE ma immagino anche in altre distribuzione, ogni volta che si apportano modifiche al sistema installando o rimuovendo software o anche solo modificando un parametro, viene scattata una istantanea pre e post.

Anche i classici backup rimangono comunque molto (troppo) onerosi di risorse quando si tratta di archiviare dischi virtuali: bisogna disegnare strategie dedicate in quei casi.

BTW stavo guardando come deframmentare manualmente e sono incappato in questa citazione, che non ho ben compreso. Potreste cortesemente chiarirmi se vi va?

Defragmentation does not preserve extent sharing, e.g. files created by cp --reflink or existing on multiple snapshots. Due to that the data space consumption may increase.

Oltretutto, se lancio una deframmentazione manuale seguendo questo comando, c'è modo di avere sott'occhio uno stato di avanzamento, un progress percentuale o similari? Ho provato a lanciarlo, ma non vedo nulla in stdout (a parte il led del disco che blinka compulsivamente)

[saxtro]

Vedila cosi:
1. hai il subvolume /home
2. creai la snapshot /home/home-snap
3. lanci il defrag su /home senza fare modifiche

Alla fine del defrag, è attesa ancora una snapshot con peso zero. Quello che potrebbe succedere, è che il defrag potrebbe creare dei duplicati, con conseguente aumento dello spazio utilizzato dalla snapshot.
In pratica, parte dello spazio condiviso, potrebbe essere raddoppiato in spazio esclusivo della snapshot e spazio esclusivo del subvolume, pur avendo avendo ancora lo stesso checksum.

[emanuc]

Rimane un dubbio però...

Se escludessi @home dagli snapshot, causa dischi virtuali delle vm, escluderei dagli snapshot anche le installazioni snap (non stanno mica nella home o sbaglio?)

Le app "snap" sono sul percorso: "/snap", sulla home ci sono le conf utente, ed i service systemd per montare le app snap sono sulla cartella di systemd. Ma non puoi escludere le app snap: https://forum.snapcraft.io/t/create-btr ... ions/15198
Ma comunque, la raccomandazione è proprio quella di escludere le APP dal rollback, in modo da evitare l'annullamento delle installazione e degli update. Ed è uno dei motivi del perché creo un subvol per le app flatpak, ma per flatpak è semplice farlo, basta un subvol di "/var/lib/flatpak" o "/home/user/.var" per le installazioni per utente. Faccio la stessa cosa nella cartella "dati" di flatpak sulla home utente,

Codice: Seleziona tutto

670     210252  666             @home/emanu/.var
969     210206  5               var_lib_libvirt

[emanuc]

Anche i classici backup rimangono comunque molto (troppo) onerosi di risorse quando si tratta di archiviare dischi virtuali: bisogna disegnare strategie dedicate in quei casi.

BTW stavo guardando come deframmentare manualmente e sono incappato in questa citazione, che non ho ben compreso. Potreste cortesemente chiarirmi se vi va?

Defragmentation does not preserve extent sharing, e.g. files created by cp --reflink or existing on multiple snapshots. Due to that the data space consumption may increase.

Oltretutto, se lancio una deframmentazione manuale seguendo questo comando, c'è modo di avere sott'occhio uno stato di avanzamento, un progress percentuale o similari? Ho provato a lanciarlo, ma non vedo nulla in stdout (a parte il led del disco che blinka compulsivamente)

Per i backup ti consiglio "borg" che ha il dedup e compressione.
L'avvertimento nella documentazione indica che se si deframmenta il subvolume X e questo ha degli snapshot, la deframmentazione annullerà tutte le condivisioni tra il subvolume e gli snapshot, occupando tutto lo spazio nello snapshot. Ad esempio, se al momento dello snapshot il subvolume era di 7 GB, lo snapshot occuperà 7 GB più lo spazio aggiuntivo del subvolume.
Tuttavia, se non hai abilitato gli snapshot per quel subvolume, non è necessario preoccuparsene. È importante ricordare che se hai abilitato la compressione e desideri mantenerla durante la deframmentazione, devi aggiungere il flag per la ricompressione dei dati, che è "-czstd" per l'algoritmo Zstd.
Vale la stessa cosa per le copie che sfruttano il "reflink".
PS: Dai una lettura a questo post: https://wiki.tnonline.net/w/Btrfs/Defrag

[saxtro]

...
Ad esempio, se al momento dello snapshot il subvolume era di 7 GB, lo snapshot occuperà 7 GB più lo spazio aggiuntivo del subvolume.
...

Scritta cosi sembra un evento certo (che le snapshot allocano tutto lo spazio che referenziano dopo il defrag del subvolume di cui sono snapshot).

[korda]

Per i backup ti consiglio "borg" che ha il dedup e compressione.

Faccio già anche il pruning e il compacting dei segmenti liberati ogni volta ma, per tenermi sicuro dal non sfondare il disco di backup non conservo più di 8 snapshot (3 daily, 3 weekly e 2 monthly)

L'avvertimento nella documentazione indica che se si deframmenta il subvolume X e questo ha degli snapshot, la deframmentazione annullerà tutte le condivisioni tra il subvolume e gli snapshot, occupando tutto lo spazio nello snapshot. Ad esempio, se al momento dello snapshot il subvolume era di 7 GB, lo snapshot occuperà 7 GB più lo spazio aggiuntivo del subvolume.
Tuttavia, se non hai abilitato gli snapshot per quel subvolume, non è necessario preoccuparsene.

Ok

È importante ricordare che se hai abilitato la compressione e desideri mantenerla durante la deframmentazione, devi aggiungere il flag per la ricompressione dei dati, che è "-czstd" per l'algoritmo Zstd.
Vale la stessa cosa per le copie che sfruttano il "reflink".

Ho la compressione abilitata in fstab (compress=zstd:1), devo editare il file o metto quella opzione sul comando di defrag?

PS: Dai una lettura a questo post: https://wiki.tnonline.net/w/Btrfs/Defrag

Grazie della risorsa, ora la leggo...

[emanuc]

...
Ad esempio, se al momento dello snapshot il subvolume era di 7 GB, lo snapshot occuperà 7 GB più lo spazio aggiuntivo del subvolume.
...

Scritta cosi sembra un evento certo (che le snapshot allocano tutto lo spazio che referenziano dopo il defrag del subvolume di cui sono snapshot).

Si, è certo, con il defrag rompi il collegamento tra subvol e snap, cosa diversa con l'opzione "autodefrag".
La nota è per avvertire che causerà l'aumento improvviso di spazio

[saxtro]

D'accordo, ma l'aumento di spazio è funzione dello stato degli oggetti che si deframmentano.

Eseguito con e senza l'opzione -r sul mio subvolume /




Le snaphost non hanno allocato tutto lo spazio che referenziano, giusto 100Mb sono stati allocati extra. L'aumento è stato improvviso, ma di modesto impatto