Linux / ext4, XFS e Btrfs: differenze e criteri di scelta

Per scegliere tra ext4, XFS e Btrfs, confronta supporto della distribuzione, funzioni necessarie, ridimensionamento e recupero prima di chiederti quale sia più recente. Valuta ext4 per strumenti familiari e riduzione a file system smontato, XFS per server con grandi volumi e accessi concorrenti, Btrfs per snapshot, compressione e checksum dei dati integrati. Sono punti di partenza: prestazioni e adeguatezza operativa vanno verificate nel tuo ambiente.

Il confronto riguarda dischi locali di PC Linux e server generici. Un file system organizza contenuti dei file e informazioni come nomi, posizione e permessi per poterli conservare e ritrovare. Per distinguere i livelli sottostanti consulta dischi, partizioni e file system.

Differenze principali tra ext4, XFS e Btrfs

I metadati descrivono posizione, dimensione e permessi dei file. Il journaling registra cambiamenti per aiutare a ristabilire la coerenza del file system dopo uno spegnimento imprevisto: non sostituisce un backup e non garantisce la conservazione di ogni contenuto. Il Copy-on-Write (CoW), o copia alla scrittura, scrive i contenuti modificati in nuovo spazio e aggiorna i riferimenti.

«No» indica l’assenza della funzione nel file system stesso. ext4 e XFS possono usare snapshot del Logical Volume Manager (LVM, gestore dei volumi logici), dello storage o della piattaforma di virtualizzazione. Le copie con condivisione dei blocchi, come i reflink XFS, sono diverse da uno snapshot dell’intero file system a un dato istante. La riga sui checksum riguarda i contenuti ordinari dei file: non significa che ext4 e XFS non proteggano i metadati. I/O indica operazioni di ingresso e uscita dei dati.

ext4: gestione familiare e riduzione offline

ext4, abbreviazione di Fourth Extended Filesystem, prosegue la famiglia ext2 ed ext3. La guida ufficiale all’installazione di Debian 13 indica ext4 come scelta predefinita nella maggior parte dei casi. È un candidato da valutare insieme agli strumenti di installazione e recupero della distribuzione quando non servono funzioni particolari. Essere predefinito non dimostra che sia sempre più veloce o più sicuro delle alternative.

La modalità ordinaria data=ordered registra nel journal i metadati e ordina la scrittura dei dati associati. Non conserva nel journal una seconda copia di tutti i contenuti. Dopo un’interruzione di alimentazione, riuscire a montare il file system è diverso dal ritrovare tutte le ultime scritture dell’applicazione. La documentazione ext4 del kernel Linux descrive le modalità e i relativi limiti.

Una differenza pratica è la riduzione. resize2fs può espandere ext4 da montato quando kernel e file system lo consentono; per ridurlo occorre smontarlo. Ridurre la radice del sistema richiede normalmente un ambiente di avvio separato e un’interruzione del servizio. Il programma non ridimensiona le partizioni: occorre gestire distintamente file system e spazio sottostante. Controlla le condizioni nel manuale resize2fs.

Se prevedi di ridistribuire spazio tra sistema operativo e dati, considera prima possibilità di riduzione e tempi di fermo. Se invece il requisito principale è tornare a uno stato precedente mediante snapshot, ext4 da solo non basta: serve progettare anche il livello LVM, di snapshot o di backup pertinente.

XFS: grandi volumi e accessi concorrenti sul server

XFS organizza lo spazio in gruppi di allocazione ed è da valutare per grandi file e operazioni concorrenti di più processi. Red Hat Enterprise Linux (RHEL) 10 lo usa come file system locale predefinito. Se strumenti, competenze e procedure di recupero della tua distribuzione sono già centrati su XFS, anche questo supporto operativo conta nella scelta. Consulta la guida RHEL 10 alla gestione dei file system.

L’espansione con xfs_growfs avviene sul file system montato. Il dispositivo sottostante deve già offrire lo spazio aggiuntivo: aumentare soltanto disco o volume logico non porta automaticamente il file system alla nuova capacità. Nel piano distingui disco, partizione, volume logico e file system.

Non descrivere la riduzione XFS né come impossibile in assoluto né come generalmente disponibile. Le note di RHEL 10.0 presentano come Technology Preview una riduzione limitata all’ultimo gruppo di allocazione, a condizione che nell’intervallo da rimuovere non siano allocati dati o metadati. Non è una procedura generale per raggiungere una dimensione arbitraria. Se ridurre lo spazio è essenziale, verifica il supporto di produzione della release effettiva oppure pianifica backup e ripristino in un nuovo file system più piccolo. Le condizioni sono nelle note RHEL 10.0 sulla riduzione limitata di XFS e nel manuale xfs_growfs.

Per un file server o un server con grandi file di dati, includi XFS fra i candidati senza decidere soltanto dalla dimensione dei file. Verifica frequenza di creazione e cancellazione dei file piccoli, numero di lavori concorrenti, scritture sincrone e latenza richiesta con un carico vicino al servizio reale.

Btrfs: snapshot, compressione e checksum insieme

Btrfs usa CoW e offre sottovolumi, snapshot, compressione trasparente e checksum di dati e metadati. Un checksum è un valore calcolato dai contenuti per rilevare se ciò che viene riletto differisce. Fedora usa Btrfs come impostazione predefinita nelle edizioni desktop e negli spin; ciò non implica supporto per ogni server o combinazione di dischi. Consulta l’introduzione ufficiale alle funzioni Btrfs e la guida Fedora a Btrfs.

Un sottovolume è un albero di directory gestibile indipendentemente all’interno del file system. Uno snapshot condivide inizialmente i blocchi con l’origine e occupa altro spazio al cambiare dei contenuti. Può conservare lo stato prima di un aggiornamento, ma scegliere Btrfs non configura da solo snapshot automatici, conservazione o menu di recupero all’avvio. Verifica insieme strumenti della distribuzione e disposizione dei sottovolumi.

Uno snapshot sullo stesso disco non sostituisce un backup separato. Origine e snapshot dipendono dallo stesso dispositivo e da blocchi condivisi: un guasto o un danno a quei blocchi può coinvolgerli entrambi. I sottovolumi annidati non sono inclusi ricorsivamente nello snapshot del genitore. Per un’applicazione che scrive, come un database, serve anche un backup applicativo o una sospensione coordinata delle scritture per ottenere dati coerenti. La documentazione dei sottovolumi e snapshot Btrfs ne chiarisce ambito e limiti.

Rilevare un errore e ripararlo sono capacità distinte. btrfs scrub verifica checksum e altre informazioni; per riparare un blocco danneggiato serve una copia ridondante verificata come integra. Su un singolo disco con una sola copia dei dati, rilevare il danno non fornisce il contenuto originario. Inoltre i file NOCOW, configurati senza CoW, costituiscono un’eccezione al controllo dei contenuti tramite checksum. Leggi i limiti nella documentazione ufficiale di scrub.

La compressione può ridurre spazio e I/O secondo la natura dei dati; video e archivi già compressi possono trarne poco beneficio. Per immagini di macchine virtuali (VM) e database con frequenti sovrascritture valuta insieme CoW, frammentazione e conservazione degli snapshot. Applicare NOCOW indiscriminatamente per aumentare le prestazioni incide anche sui checksum dei dati e sulla compressione. Le interazioni sono descritte nelle opzioni di montaggio Btrfs.

Se combini dischi, valuta separatamente ogni profilo RAID, Redundant Array of Independent Disks, cioè un insieme coordinato di dischi. L’introduzione ufficiale descrive RAID5/6 come sperimentali e non pronti per la produzione. Non equipararli agli altri profili: controlla kernel, strumenti e stato delle singole funzioni Btrfs.

Quale scelta corrisponde al tuo ambiente?

I criteri seguenti collegano funzioni e necessità concrete. Non sono una classifica né una configurazione raccomandata universalmente.

Se lo scopo principale è annullare un aggiornamento fallito del sistema operativo, verifica quali sottovolumi ripristina davvero lo strumento di recupero. Il progetto cambia se vuoi mantenere aggiornati i dati degli utenti oppure riportare dati e sistema allo stesso istante. Su un server il cui spazio dati cresce soltanto, supporto, espansione e backup possono pesare più della riduzione.

Condizioni da allineare nel confronto delle prestazioni

Il nome del file system non basta a prevedere la velocità. Sullo stesso SSD, un’unità a stato solido, creare molti file piccoli, leggere sequenzialmente un file grande e scrivere in modo sincrono su un database possono dare risultati differenti. Copie brevi possono essere influenzate soprattutto dalla cache in memoria.

• Dispositivo: usa lo stesso SSD o disco rigido HDD, collegamento, occupazione e spazio libero.
• Carico: allinea dimensioni e numero di file, proporzione fra letture e scritture, accessi sequenziali o casuali e concorrenza.
• Funzioni e impostazioni: registra compressione, CoW, snapshot, cifratura e opzioni di montaggio. Non presentare funzioni abilitate e disabilitate come condizioni identiche.
• Durabilità: allinea scritture sincrone dell’applicazione e politiche della cache del dispositivo. Indebolire le garanzie di conservazione non equivale semplicemente a migliorare le prestazioni.
• Versioni e misure: registra kernel e strumenti; osserva latenza e variazione fra prove ripetute oltre alla quantità di dati trasferita al secondo.

Per un server di log, per esempio, prova scrittura in append, rotazione, compressione e backup sovrapposti, non soltanto la copia di un file grande. Considera sia il risparmio di spazio sia il costo di elaborazione della compressione. Se il vantaggio misurato è piccolo, valuta anche costo e rischio della migrazione del file system esistente.

Verificare il formato attuale e pianificare le modifiche

Consultare lo stato senza cambiarlo

In un normale ambiente Linux, i comandi seguenti interrogano dispositivi, montaggi e capacità. lsblk e findmnt appartengono a util-linux; su GNU/Linux df proviene normalmente da coreutils. Non creano un file system e non ne cambiano il formato. Eseguili separatamente e controlla eventuali errori.

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
findmnt -T / -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT /

In lsblk osserva gerarchia dei dispositivi e FSTYPE; findmnt mostra tipo e opzioni effettive del file system che contiene la radice. df -hT / riporta tipo e capacità per quel percorso. Per esaminare i dati usa la loro directory effettiva al posto di /.

Se findmnt indica xfs in FSTYPE, quel percorso è su XFS. La riga del disco può avere FSTYPE vuoto mentre una partizione o un volume logico mostra il formato. In un container potresti vedere overlay: non dedurne il formato del disco dell’host. Se una vecchia versione di lsblk non supporta MOUNTPOINTS, prova MOUNTPOINT; il plurale può elencare più punti di montaggio. Consulta i manuali lsblk e findmnt.

Se lo spazio Btrfs non corrisponde alle aspettative, btrfs filesystem usage aiuta a distinguere dati, metadati e allocazione sui dispositivi. File eliminati possono restare referenziati dagli snapshot e non liberare subito lo spazio atteso. Non basarti soltanto sulla somma delle directory: consulta la documentazione Btrfs su uso dello spazio e ridimensionamento.

Migrare verso un file system diverso

Eseguire un mkfs di altro formato su un file system esistente non è una conversione che conserva i dati. Un piano generale basato su nuova destinazione e ripristino verificato rende più chiari controllo e ritorno allo stato precedente.

1. Identifica dispositivo di origine, formato e punto di montaggio, verifica il supporto applicativo, poi crea un backup su storage indipendente e provane il ripristino.
2. Prepara il file system di destinazione su un disco nuovo o su un’area disponibile separatamente. Prima di formattare riconferma che sia proprio la destinazione vuota prevista.
3. Ottieni dati coerenti fermando il servizio o usando il backup dell’applicazione. Copia o ripristina proprietà, permessi, liste di controllo degli accessi (ACL), attributi estesi e collegamenti fisici richiesti. Copiare i contenuti non garantisce di preservare tutti questi metadati.
4. Verifica file e applicazione nel nuovo percorso, poi aggiorna /etc/fstab e le impostazioni dei servizi con il nuovo UUID, identificatore univoco del file system. La migrazione della radice del sistema richiede una procedura distinta per boot loader e ambiente iniziale di avvio.
5. Dopo il riavvio verifica montaggi, servizi e permessi. Conserva origine e backup fino alla conferma del passaggio. In caso di problemi ferma le scritture sulla destinazione e prepara il ritorno a origine e impostazioni verificate, includendo nel piano anche i dati creati dopo il passaggio.

Anche ridimensionare mantenendo il formato richiede un ordine corretto fra i livelli. Di norma espandi prima lo storage sottostante e poi il file system; quando la riduzione è supportata, riduci prima il file system e poi lo spazio sottostante. Il ridimensionamento Btrfs non aggiorna automaticamente la tabella delle partizioni. Sono principi, non una procedura completa: cifratura, LVM e RAID richiedono passaggi supportati specifici.

Gli strumenti di recupero non sono intercambiabili: e2fsck per ext4, xfs_repair per XFS e gli strumenti Btrfs vanno scelti secondo il formato effettivo. In particolare non usare btrfs check --repair come primo tentativo ordinario: la documentazione lo sconsiglia senza indicazioni di uno sviluppatore o utente esperto. Leggi fsck e le precauzioni per i controlli specifici e l’avvertenza ufficiale sul controllo Btrfs, preparando prima backup e piano di recupero.