ZFS è il file system che si incontra quasi sempre in un homelab: lo propongono Proxmox VE, TrueNAS e molte distribuzioni Linux. Alcune scelte fatte il primo giorno non si possono più cambiare, quindi conviene capirne la struttura prima di creare il pool.
File system e gestore dei volumi insieme
Con ext4 o XFS ci sono livelli separati: il controller RAID o mdadm unisce i dischi, LVM crea i volumi, il file system organizza i file. ZFS fa tutto da solo. Questo gli permette di sapere esattamente quali blocchi sono in uso, di verificare ogni lettura con un checksum e di ricostruire solo i dati reali dopo un guasto, non l'intero disco.
La gerarchia è questa:
- pool (zpool): lo spazio complessivo che vedi;
- vdev: i gruppi di dischi che compongono il pool;
- dataset e zvol: le suddivisioni logiche del pool, rispettivamente file system e dispositivi a blocchi (questi ultimi usati per i dischi delle macchine virtuali).
Il punto chiave: la ridondanza sta nei vdev
La regola da imparare a memoria è che la ridondanza esiste dentro ogni vdev, non tra i vdev. Il pool distribuisce i dati su tutti i vdev; se un vdev intero si guasta, si perde l'intero pool.
Le configurazioni tipiche dei vdev:
| Tipo | Dischi minimi | Guasti tollerati | Note |
|---|---|---|---|
| Mirror | 2 | tutti tranne uno per vdev | ottime prestazioni casuali, resilver rapido |
| RAIDZ1 | 3 | 1 | sconsigliato con dischi grandi |
| RAIDZ2 | 4 | 2 | buon compromesso per l'archiviazione |
| RAIDZ3 | 5 | 3 | per array molto ampi |
Per lo storage delle macchine virtuali, dove contano le letture e scritture casuali, i mirror sono quasi sempre la scelta migliore: più mirror affiancati si comportano come un RAID 10. Per un archivio di file grandi, come foto e video, un RAIDZ2 offre più spazio utile a parità di dischi.
Un errore classico è aggiungere a un pool in RAIDZ2 un singolo disco come nuovo vdev: senza ridondanza, diventa il punto debole dell'intero pool.
Scelte da fare prima di creare il pool
ashift
Il parametro ashift indica la dimensione minima del settore che ZFS usa. Quasi tutti i dischi moderni hanno settori fisici da 4 KiB, quindi si usa ashift=12. Si imposta alla creazione del vdev e non si cambia più: un valore troppo basso su dischi da 4 KiB peggiora le prestazioni in modo permanente.
Espansione
Aggiungere un vdev a un pool è sempre stato possibile. Allargare un vdev RAIDZ con un disco in più è arrivato solo con le versioni recenti di OpenZFS, e i dati già scritti mantengono il vecchio rapporto tra dati e parità finché non vengono riscritti. Un mirror, invece, si espande sostituendo uno alla volta i dischi con modelli più grandi. Se prevedi di crescere, i mirror sono più flessibili.
Dischi adatti
Gli hard disk con registrazione SMR possono rendere la ricostruzione lentissima o farla fallire per timeout. Per ZFS vanno scelti dischi CMR, verificando la scheda tecnica del modello esatto.
ARC: perché ZFS usa tanta RAM
ZFS mantiene in memoria una cache chiamata ARC (Adaptive Replacement Cache). È normale vedere una parte consistente della RAM occupata: viene rilasciata quando servono memoria ad altri processi, anche se non sempre con la rapidità desiderata. Su un host di virtualizzazione è prudente limitarla, ad esempio con il parametro zfs_arc_max, così da lasciare spazio garantito alle macchine virtuali.
I dispositivi aggiuntivi vanno usati con giudizio:
- L2ARC: cache di lettura su SSD; ha senso solo quando l'ARC è già grande e il carico di lavoro rilegge spesso gli stessi dati;
- SLOG: accelera solo le scritture sincrone, come quelle di NFS o di alcuni database; deve essere un SSD con protezione da mancanza di corrente;
- special vdev: ospita i metadati su SSD; se si perde, si perde il pool, quindi va sempre in mirror.
Funzioni da usare ogni giorno
- Compressione:
lz4ozstdvanno attivate quasi sempre. Riducono lo spazio occupato e spesso aumentano le prestazioni, perché si leggono meno dati dal disco. - Snapshot: istantanee a costo quasi nullo, perfette prima di un aggiornamento. Strumenti come Sanoid creano e ruotano snapshot orari, giornalieri e mensili.
- Replica:
zfs sendezfs receivetrasferiscono snapshot su un'altra macchina in modo incrementale. È la base di un buon backup, ma la copia deve stare su hardware diverso.
Un esempio di creazione di un pool con due mirror:
zpool create -o ashift=12 tank \
mirror /dev/disk/by-id/ata-DISCO1 /dev/disk/by-id/ata-DISCO2 \
mirror /dev/disk/by-id/ata-DISCO3 /dev/disk/by-id/ata-DISCO4
zfs set compression=lz4 tank
Si usano i percorsi /dev/disk/by-id/ perché i nomi come /dev/sda possono cambiare tra un avvio e l'altro.
Scrub e controllo dello stato
Lo scrub rilegge tutti i dati del pool e ne verifica i checksum, correggendo gli errori grazie alla ridondanza. Molte distribuzioni lo pianificano già una volta al mese; nel mio lavoro lo considero il minimo indispensabile. Il comando zpool status mostra lo stato dei vdev e gli eventuali errori di lettura, scrittura o checksum: va controllato, oppure collegato a un sistema di notifiche come ZED, il demone di eventi di ZFS, che può inviare email quando un disco si degrada.
In sintesi
- La ridondanza è nei vdev: se un vdev si guasta, si perde tutto il pool.
- Mirror per le macchine virtuali, RAIDZ2 per l'archiviazione di file grandi.
ashift=12, dischi CMR e percorsi by-id vanno decisi alla creazione.- L'ARC usa molta RAM per scelta; su un hypervisor conviene porle un limite.
- Compressione attiva, snapshot automatici, replica su un'altra macchina e scrub mensile.
