Se abbiamo una installazione Linux su filesystem ext4 possiamo facilmente passare a btrfs senza dover reinstallare tutto il sistema... Come? Conviene? Vediamo un esempio pratico di conversione su un sistema con partizione criptata.
ext4, la 4 versione dell'extended filesystem, è (ancora) il filesystem scelto come impostazione predefinita per molte distro Linux e questo è dovuto alla sua maturità che si traduce in stabilità e prestazioni ma anche perché ha limiti (dimensione massima del disco, numero massimo di file, dimensione massima di un file,... ) propri di ogni filesystem considerati ancora molto ampi, soprattutto in ambito Desktop. Ma oggi c'è un nuovo concorrente: btrfs.
Al contrario di ext4 è piuttosto giovane (in realtà neanche tanto dato che è stato introdotto nel 2019... ) ma considerato sicuro anche per sistemi di produzione, nonostante alcune particolari caratteristiche siano sempre in fase di sviluppo e che inizia ad essere adottato per impostazione predefinita da alcune distro come Fedora (sempre all'inseguimento dell'innovazione) e OpenSuse (promotrice e direttamente coinvolta nello sviluppo di btrfs).
Prima di vedere quali sono le principali differenze tra questi due filesystem, facciamo un passo indietro...
Che cosa è il "filesystem"?
Possiamo definire il filesystem come il modo in cui vengono ordinati i dati sul disco. L'operazione che ci consente di creare un filesystem su una partizione di un disco, è la "formattazione", termine quest'ultimo associato più all'idea di "distruzione/cancellazione dei dati" che alla costruzione di qualcosa... in effetti, cambiando o sovrascrivendo il metodo di organizzazione, i dati preesistenti possono andar perduti per sempre.
Se ancora non fosse chiaro, possiamo fare un semplice esempio, pensiamo ad un disco (sia esso meccanico o SSD), o meglio ad una partizione di un disco, come ad un foglio di carta completamente bianco; il filesystem potrebbe essere benissimo rappresentato dalla creazione di quadretti che verranno poi utilizzati per incasellare i caratteri del testo che andremo a scrivere; in questo esempio, il singolo carattere rappresenta la quantità massima di bit archiviabile in un blocco del filesystem (il quadretto) mentre un'intera parola rappresenta un intero file.
Ma un filesystem è responsabile anche di molte altre funzioni come la gestione dei dati correlati (i metadati, anche questi contenuti in uno o più quadretti) e degli attributi di un file o la gestione dei permessi e delle quote più altre caratteristiche proprie di ogni filesystem che lo rendono idoneo o meno ad essere utilizzato per scopi diversi: ad esempio, potete utilizzare exFAT per lo scambio di file fra sistemi operativi ma meglio non installarci nessun sistema operativo!
ext4 vs btrfs: quali differenze?
Ma quali sono le differenze tra l'uno e l'altro e quale conviene scegliere? Lasciando perdere i limiti massimi riguardo numero e grandezza file e dischi che per entrambi i filesystem sono più che abbondanti per l'utente Desktop, btrfs ha molte caratteristiche avanzate che consentono una gestione del sistema più snella (soprattutto in ambito server) tra queste conviene citarne alcune.
La prima e, a mio avviso, più importante differenza tra i due è che btrfs si basa sul principio di copy-on-write (COW, copia-in-scrittura) mentre ext4 si basa sul Journaling, caratteristiche entrambe volte a garantire l'integrità dei dati. btrfs, con l'opzione di COW attiva, fa sì che durante la modifica di un file già esistente, questo non viene direttamente sovrascritto ma viene copiato con l'aggiunta delle modifiche.
È evidente come qualunque problema si presentasse durante la modifica di detto file, lo stato originale di questo non venga in alcun modo alterato, scongiurando la perdita di dati. Per confronto il Journaling di ext4, tiene traccia delle modifiche non ancora scritte al file, riducendo (non scongiurando!) la possibilità di corruzione del file.
Se pensate che il COW renda necessario più spazio su disco per salvare i file, vi state sbagliando: la copia del file viene fatta in maniera efficiente, sostanzialmente salvando solo la modifica effettuata (in un altra posizione sul disco) e per la parte invariata si fa riferimento al file originale; lo spazio occupato dalla porzione del file modificata, viene marcata per essere normalmente riutilizzata.
Oltre a questa sostanziale differenza, btrfs implementa diverse funzioni che ext4 non ha; alcune delle più interessanti tra queste:
- compressione dei dati: è possibile scegliere di salvare direttamente i dati su disco compressi secondo un algoritmo scelto. Questo consente di risparmiare spazio su disco a costo di un carico maggiore su CPU e RAM.
- possibilità di autodefrag: se avete timori che il COW possa portare ad eccessiva frammentazione dei dati, è possibile (con l'opzione di mount autodefrag) far sì che btrfs "deframmenti" automaticamente i file.
- controllo dell'integrità di dati e metadati: funzione che, insieme ad altre caratteristiche, consente anche di riparare i file danneggiati e correggere alcuni errori.
- subvolume: offre la possibilità di creare dei subvolume che possono essere visti come partizioni (e come tali possono avere alcune opzioni di mount diverse) ma senza dover scegliere a priori la dimensione; ogni subvolume avrà la possibilità di utilizzare tutto lo spazio su disco disponibile senza limitazione alcuna!
- snapshot: altra caratteristica molto interessante, è la possibilità di creare delle "immagini" di ogni subvolume che possono, in caso di necessità, essere ripristinate eliminando ogni modifica fatta al subvolume successiva alla creazione dello snapshot; grazie al COW, lo spazio occupato dagli snapshot riguarda solo le modifiche effettuate. Parte dello spazio occupato dagli snapshot può essere recuperato grazie ad un altra caratteristica (data deduplication) che fa sì che, con programmi appositi, copie dei dati già presenti possano essere sostituite con riferimenti all'originale.
- RAID: è possibile creare diverse configurazioni di RAID proprio a livello di filesystem.
Immagino che a questo punto, alcuni di voi, probabilmente staranno pensando alle prestazioni; purtroppo non si trovano molti test recenti di comparazione tra i due, solo vaghe asserzioni non supportate da dati o che fanno riferimento a benchmark piuttosto datati come quelli riportati qui sotto che risalgono al 2016 e al 2021, dal quale risulta che ext4 è superiore in quasi tutti i test di scrittura e lettura.
Dobbiamo tenere conto che alcune opzioni di mount possono variare le prestazioni di entrambi i filesystem (magari a discapito di qualche funzione) e anche che Btrfs, ancora in fase di sviluppo attivo, può avere margini di miglioramento. Da questi dati sembra però che le prestazioni non siano l'obbiettivo principale di Btrfs che, con le sue funzioni, punta piuttosto sulla consistenza e sull'integrità dei dati. Infine da sottolineare il fatto che con i moderni dischi SSD, per il normale utilizzo Desktop, la differenza di prestazioni non è avvertibile dall'utente durante l'utilizzo.
Adesso che abbiamo (spero) chiarito un po' le idee sulle differenze di questi filesystem possiamo meglio valutare se conviene effettuare il passaggio a btrfs; in caso di risposta affermativa, vediamo la procedura per la conversione!
etx4 -> btrfs: come fare?
Per prima cosa passiamo ai requisiti fondamentali:
- dato che dal sistema in uso non è possibile convertire la partizione dove risiede il sistema stesso, occorrerà un dispositivo con un immagine Live meglio se della stessa distro del nostro sistema;
- sufficiente spazio su disco libero, difficile da quantificare con esattezza ma, indicativamente, almeno il 20%;
- anche se è una procedura sicura, una copia di backup del sistema;
- anche se è una procedura sicura, un altra copia di backup dei dati più importanti.
Come accennato questa guida fa riferimento ad un sistema con la partizione contenente la / criptata con LUKS (il sistema comprende quindi anche altre 2 partizioni non criptate: /boot e /boot/efi). Questo non è un grosso problema: invece di agire direttamente sulla partizioni andremo a lavorare con il volume decriptato (ad esempio, invece di indicare la partizione /dev/sda3, utilizzeremo /dev/dm-0 dopo averla decriptata).
Avviamo il sistema Live, apriamo un Terminale e identifichiamo la partizione interessata, ad esempio, con lsblk. Io la riconosco dalla dimensione, so che questa è criptata e devo quindi prima decriptarla con cryptsetup; il semplice comando sarà:
sudo cryptsetup luksOpen /dev/vda6 mint
ATTENZIONE: per semplificare le operazioni future sarà meglio utilizzare lo stesso nome impostato nel sistema per indicare a cryptsetup come chiamare il volume decriptato; altrimenti dovrete cambiare il nome nei file /etc/crypttab e /etc/fstab come ho dovuto fare io!
Verifichiamo poi a quale dispositivo è collegato il nome del volume appena decriptato, semplicemente con ls -l /dev/mapper/; nell'esempio è /dev/dm-0, io utilizzerò questo ma potete utilizzare benissimo anche /dev/mapper/mint se preferite
Prima di passare alla conversione, sarà meglio accertarsi che il filesystem esistente non presenti errori, per farlo sarà sufficiente lanciare il comando sudo e2fsck -fyv /dev/dm-0 al termine del quale potremo avviare la conversione vera e propria digitando
sudo btrfs-convert -p /dev/dm-0
La stringa "Conversion complete", al termine dell'operazione, ci assicura che la conversione è già stata fatta! Ma il lavoro non finisce qui: per assicurarci di trarre il massimo vantaggio da btrfs infatti dovremo creare almeno due subvolume (/ e /home) ma nessuno ci vieta di crearne di più (magari /tmp, /var, ...) in modo da poter assegnare opzioni di mount diverse per ognuno dei subvolume.
Per prima cosa, montiamo il dispositivo appena convertito a btrfs in /mnt ed andiamo a lavorare da questo percorso:
sudo mount /dev/dm-0 /mnt
cd /mnt
Per creare il subvolume della / facciamo uno snapshot dell'attuale radice di sistema mentre potremo creare un nuovo subvolume per /home dove andremo a copiare subito tutti i dati; i comandi sono
sudo btrfs subvolume snapshot ./ ./new_root
sudo btrfs subvolume create ./new_home
sudo cp -a ./home/* ./new_home
Adesso potremo rimuovere tutto il contenuto della vecchia radice di sistema (che, ricordo, abbiamo montato in /mnt) ad esclusione di tre cartelle, quelle appena create (new_root e new_home) e ext2_saved, cartella creata dalla procedura di conversione, che ci consente, in caso di pentimento, di tornare al vecchio filesystem. Per farlo possiamo cancellare una alla volta tutte le cartelle diverse da quelle dette oppure impartire un paio di comandi:
shotp -s extglob
sudo rm -rfv !("new_root"|"new_home"|"ext2_saved")
Il primo comando imposta un'opzione della shell in uso (Bash) per estendere la ricerca delle corrispondenze tramite modelli e questo è necessario per far funzionare correttamente il secondo comando che rimuove tutto ciò che è presente nel corrente percorso di lavoro ad esclusione delle tre cartelle elencate; lasciamo terminare il comando e poi verifichiamo la sola presenza delle nostre tre cartelle, con il comando ls -l.
Ora che non c'è più pericolo di confondersi con i nomi, se vogliamo, possiamo anche rinominare le cartelle new_root e new_home (io ho scelto di rinominarle come root e home) ma potete anche saltare questo passaggio e continuare a lavorare con i nomi assegnati; poi elimineremo tutto il contenuto della cartella root/home perché questa sarà la cartella dove verrà montato il subvolume /home, dove già abbiamo copiato i file dei/del nostri/nostro utenti/utente:
mv new_root root
mv new_home home
rm -rf root/home/*
Siamo a buon punto ma manca ancora qualche operazione da fare per far sì che il nostro sistema si possa avviare!
Il prossimo passo è modificare il file /etc/fstab (che si troverà nel percorso /mnt/root/etc/fstab) per indicare il nuovo filesystem e i due subvolume appena creati. Dovremo quindi sostituire la stringa che fa riferimento alla partizione ext4 con due stringe che indicano i due subvolume; le nuove stringe saranno simili alle seguenti
/dev/mapper/mint / btrfs subvol=root 0 0
/dev/mapper/mint /home btrfs subvol=home 0 0
Lascio a voi la scelta di altre opzioni di mount da aggiungere ad ognuno dei subvolume.
L'ultimo passo è aggiornare l'initramfs e grub per indicare la modifica al filesystem e per farlo occorrerà "entrare" nel sistema con chroot. Prima di proseguire meglio installare il pacchetto arch-install-scripts che contiene una speciale versione di chroot che ci semplifica di molto la procedura.
È necessario smontare /mnt e rimontare il subvolume root oltre alla partizione di /boot e, dato che si tratta di un sistema EFI, anche quella di /boot/efi (il subvolume /home non è necessario per il processo di avvio e quindi non lo montiamo).
cd ..
sudo umount /mnt
sudo mount -o subvol=root /dev/mapper/mint /mnt
sudo mount /dev/vda5 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi
Infine utilizziamo arch-chroot per "entrare" nel nostro sistema
sudo arch-chroot /mnt
Adesso saranno sufficienti due soli comandi: il primo genererà una nuova immagine di initramfs (immagine del kernel che viene caricato in RAM all'avvio) e il secondo aggiornerà il bootloader GRUB:
update-initramfs -u
grub-update
Adesso possiamo uscire dal chroot (semplicemente digitando exit), smontare tutte le partizioni montate (con il comando sudo umount -a) e riavviare nel sistema così modificato.
Operazioni da fare dopo la conversione
Arrivati a questo punto possiamo sempre tornare sui nostri passi ed eventualmente riconvertire il filesystem in ext4; se invece siamo soddisfatti del nuovo filesystem possiamo fare qualche altra operazione in più per recuperare un po' di spazio e ottimizzare il sistema!
ATTENZIONE: una qualunque delle seguenti operazioni impedirà di tornare al vecchio filesystem!
La prima operazione da fare è cancellare il subvolume ext2_saved, per farlo dovremo montare il subvolume / (che è l'equivalente di montare /dev/mapper/mint senza indicare nessun subvolume!) che contiene ext2_saved, in un nuovo percorso (io ho creato una nuova cartella in /mnt/ ma se non avete nessun altro dispositivo montato in questo percorso potete usarlo direttamente senza aggiungere nessuna nuova cartella) e poi procedere all'eliminazione; dopo smontiamo il subvolume precedentemente montato (io elimino anche la cartella creata in /mnt/). I comandi saranno:
sudo mkdir /mnt/cancellare
sudo mount -o subvol=/ /dev/mapper/mint /mnt/cancellare
sudo btrfs subvolume delete /mnt/cancellare/ext2_saved
sudo umount /mnt/cancellare
sudo rmdir /mnt/cancellare
Adesso possiamo ottimizzare un po' il sistema per prima deframmentando ricorsivamente i nostri subvolume (/ e /home ma anche altri se ne avete creati!); le opzioni aggiunte ai comandi servono per rendere la deframmentazione ricorsiva (-r) e per eliminare i "pezzi" dei file già eliminati prima di passare al file successivo (-f):
sudo btrfs filesystem defragment -r -f -v /
sudo btrfs filesystem defragment -r -f -v /home
Se non avete molti file di grosse dimensioni l'operazione di deframmentazione di tutti i subvolume dovrebbe essere piuttosto veloce e al termine possiamo fare un'altra ottimizzazione del sistema, il balance, che ci consente di recuperare ancora un po' di spazio:
sudo btrfs balance -m /
Adesso abbiamo finito e il nostro nuovo filesystem è in condizioni perfette!
» Leggi: [WINDOWS] Come accedere alle partizioni formattate btrfs
