Fornito da @altbot, generato localmente e privatamente utilizzando Gemma4:26b

@linux Un'infografica intitolata "Linux Filesystem Comparison", con la dicitura "Created by Dan Nanni at study-notes.org". L'immagine presenta una tabella di confronto tra cinque file system Linux: EXT4, XFS, Btrfs, OpenZFS e Bcachefs. La tabella elenca diverse caratteristiche tecniche, tra cui Creation Timestamp, Last Read Timestamp, Access Control List, Metadata Checksum, Extended Attributes, Hard/Soft Links, File Change Log, Copy on Write, Snapshot Support, Encryption, Deduplication, Data Checksum, Persistent Cache, Compression, Self-Healing, Online Grow, Offline Shrink, Online Shrink e Add/Remove Disks. Per ogni funzionalità, la tabella riporta un segno di spunta verde per indicarne la disponibilità o una croce rossa per indicarne l'assenza nei rispettivi file system.

Energia utilizzata: 0.330 Wh

No, non ci siamo. E alcuni sono errori gravi che ti faranno fare scelte assurde, tipo escludere XFS per immagini di macchine virtuali, che funzionano MOLTO peggio su FS COW.

Questa tabella è quasi inutilizzabile, perché mescola almeno quattro concetti diversi:

• funzionalità native e automatiche;
• funzionalità disponibili solo tramite ioctl o programmi esterni;
• funzionalità opzionali, abilitate soltanto alla creazione del filesystem;
• capacità del volume manager sottostante, attribuite arbitrariamente al filesystem.

Le imprecisioni più evidenti sono queste.

XFS: «Copy on Write»

Falso o, nella migliore delle ipotesi, gravemente fuorviante.

XFS non è un filesystem CoW generale. Supporta il CoW soltanto per gli extent condivisi tramite reflink. Una copia fatta con:

`bash
cp --reflink=always sorgente destinazione

condivide inizialmente i blocchi; quando uno dei due file viene modificato, XFS copia soltanto i blocchi interessati.

Questo non rende XFS un filesystem CoW nel senso in cui lo sono Btrfs, OpenZFS o bcachefs.

## XFS: «Deduplication»

Fuorviante.

XFS supporta richieste di deduplicazione tramite `FIDEDUPERANGE`, ma la ricerca dei blocchi duplicati deve essere effettuata da un programma esterno.

Non possiede deduplicazione automatica e continua integrata nel filesystem.

## Btrfs: «Deduplication»

Anche questo è fuorviante.

Btrfs supporta reflink e deduplicazione esterna o differita, ma non esegue normalmente deduplicazione automatica in tempo reale.

Un semplice segno di spunta non distingue tra:

- deduplicazione automatica;
- deduplicazione offline;
- deduplicazione eseguita da programmi esterni;
- semplice supporto a reflink.

## «Last Read Timestamp»

Questa riga ha poco valore comparativo.

Si riferisce sostanzialmente ad `atime`, che è una caratteristica comune dei filesystem Linux e della VFS. Inoltre può essere gestita con diverse opzioni:

- `atime`;
- `relatime`;
- `strictatime`;
- `noatime`;
- `lazytime`.

Avere un timestamp di accesso non distingue seriamente un filesystem moderno da un altro.

## «File Change Log»

La voce assegnata a XFS è molto discutibile.

Il journal di XFS non è un registro persistente e facilmente interrogabile di tutte le modifiche ai file, paragonabile per esempio al journal USN di NTFS.

Probabilmente la tabella confonde:

- journaling;
- log delle transazioni interne;
- changelog consultabile delle modifiche ai file.

Sono cose differenti.

## «Persistent Cache»

La categoria è mal definita.

Nel caso di OpenZFS sembra riferirsi a L2ARC, cioè a una cache su dispositivo persistente tra un riavvio e l'altro, almeno nelle implementazioni moderne.

Ma segnare bcachefs con una croce è particolarmente assurdo: la gestione di dispositivi veloci e lenti e il caching sono parte centrale della sua architettura.

Inoltre una cache persistente non è una normale proprietà POSIX del filesystem, quindi non dovrebbe essere trattata come una semplice funzione sì/no.

## «Self-Healing»

Non è una proprietà assoluta.

Btrfs, OpenZFS e bcachefs possono correggere dati corrotti soltanto se esiste una seconda copia valida, per esempio tramite:

- mirroring;
- replica;
- RAID;
- copie multiple dei dati o dei metadati.

Su un singolo disco, il checksum permette di rilevare la corruzione, ma non di ricostruire magicamente i dati corretti.

La tabella dovrebbe quindi distinguere tra:

- rilevamento della corruzione;
- correzione tramite ridondanza;
- semplice verifica dei metadati.

## «Encryption»

La tabella mette sullo stesso piano funzioni molto diverse.

EXT4 può usare `fscrypt`, che cifra file e directory selezionati.

OpenZFS offre cifratura nativa a livello di dataset.

bcachefs dispone di cifratura nativa del filesystem.

Queste implementazioni differiscono per:

- granularità;
- gestione delle chiavi;
- cifratura dei nomi;
- metadati protetti;
- possibilità di replica o snapshot cifrati.

Un solo segno di spunta nasconde tutte queste differenze.

## «Metadata Checksum»

Anche questa voce richiede condizioni.

In EXT4 dipende dalle feature abilitate durante la creazione o l'aggiornamento del filesystem.

In XFS dipende dall'uso del formato moderno, normalmente chiamato formato V5.

Non basta quindi scrivere semplicemente «sì» senza specificare versione e configurazione.

## «Add/Remove Disks»

Qui vengono mescolati filesystem e volume manager.

Btrfs, OpenZFS e bcachefs incorporano direttamente la gestione multidisco.

EXT4 e XFS vengono normalmente usati sopra:

- LVM;
- mdraid;
- hardware RAID;
- SAN;
- dispositivi virtuali.

Dire che EXT4 o XFS non possono aggiungere dischi è quindi scorretto: semplicemente la funzione viene normalmente delegata allo strato sottostante.

## OpenZFS: «Add/Remove Disks»

Anche il segno di spunta per OpenZFS è troppo generico.

Aggiungere vdev a un pool è possibile, ma rimuovere dispositivi o ridurre il pool dipende dalla topologia.

Non tutte le configurazioni permettono di rimuovere liberamente un disco o un intero vdev.

## «Online Shrink» e «Offline Shrink»

La distinzione è troppo rozza.

Bisognerebbe separare almeno:

- riduzione del filesystem;
- riduzione del volume sottostante;
- rimozione di un dispositivo;
- riduzione di un pool;
- conversione della topologia RAID.

Per esempio, rimuovere un device da Btrfs non equivale necessariamente a eseguire uno shrink tradizionale del filesystem.

## «Creation Timestamp»

Anche questa funzione dipende da:

- formato del filesystem;
- versione del kernel;
- versione degli strumenti;
- API usate per leggerlo;
- supporto del programma che visualizza il file.

Il timestamp di creazione può esistere sul disco ma non essere mostrato da tutti gli strumenti.

## Come dovrebbe essere descritta correttamente la situazione di XFS

| Funzione | XFS |
|---|---|
| CoW generale del filesystem | No |
| Reflink | Sì, se abilitato |
| CoW degli extent condivisi | Sì |
| Snapshot nativi | No |
| Snapshot tramite LVM o storage sottostante | Possibili |
| Deduplicazione automatica | No |
| Deduplicazione tramite programma esterno | Sì |
| Checksum dei metadati | Sì, con formato V5 |
| Checksum dei dati utente | No |
| Cifratura nativa | No |
| Compressione nativa | No |
| Crescita online | Sì |
| Riduzione del filesystem | No |

In sostanza, il segno di spunta accanto a **«XFS: Copy on Write»** prende una capacità specifica, cioè il reflink, e la presenta come se descrivesse l'intera architettura del filesystem.

È come sostenere che EXT4 sia un filesystem cifrato soltanto perché può utilizzare `fscrypt`: la funzione esiste, ma non caratterizza il comportamento generale del filesystem.

@linux@mastodon.uno @linux@diggita.com

Thanks, very useful