elinvensito/content/blog/file-system-a-confronto.md

+++ title = “File system a confronto” date = “2017-08-14T23:40:15+02:00” categorie = [] draft = false [image] url = “https://gmg.elinvention.ovh/mgoblin_media/media_entries/177/pexels-photo-117729.medium.jpeg” +++

Su GNU/Linux, a differenza di altri sistemi operativi, abbiamo a disposizione un’ampia scelta di file system, ognuno con i suoi punti di forza e le sue debolezze. I file system più popolari che troviamo sui moderni sistemi GNU/Linux, sono senz’altro ext4, XFS, btrfs e ZFS.

È sempre utile tenere sotto mano i dati relativi alle prestazioni. Per questo mi affido ai dati forniti da phoronix.com, ad esempio questo articolo.

ext4

Il file system più conosciuto ed utilizzato, in quanto default di molte tra le più popolari distribuzioni come Ubuntu e Debian. Si tratta della quarta iterazione dei file system ext (EXTended file system), è stabile e veloce. Tuttavia non ha alcune caratteristiche importanti specialmente in ambito server.

Caratteristiche:

• Dimensione massima file system: 1 EiB = 1024 PiB = 1024*1024 TiB (indirizzamento a 48 bit)
• Dimensione massima di un file: 16 TiB
• Struttura contenuto delle cartelle: lista concatenata e B alberi
• Allocazione dei file: extent e bitmap
• Attributi estesi
• I/O diretto con DMA
• Allocatore multiblocco: invece di richiedere un singolo blocco alla volta, si possono richiedere all’allocatore più blocchi in una volta, in questo modo l’allocatore può evitare di frammentare un nuovo file molto grande e riduce l’overhead.
• Allocazione ritardata: ritarda l’allocazione di un file fin tanto che questo si trova in cache (ad esempio evita di scrivere su disco un file che nel mentre è stato eliminato).
• Deframmentazione in linea: nonostante gli extent, l’allocatore multiblocco e l’allocazione ritardata, la frammentazione può comunque avvenire. Per questo un processo in background si preoccupa di deframmentare il file system. In più esiste il tool e4defrag.
• Controllo dell’integrità rapido con e2fsck
• Journaling
• Barriere: appoggiandosi all’hardware, ext4 si assicura di scrivere i dati prima del commit sul journal, in modo da evitare l’inconsistenza in caso di crash.
• Cifratura trasparente per file e cartelle tramite il tool e4crypt.

Difetti:

• Non supporta i codici di controllo degli erroi contro la corruzione silenziosa dei dati (lo supporta solo per i metadati)
• Non supporta la riduzione delle dimensioni in linea
• Non supporta sottovolumi e snapshot
• Non supporta la compressione trasparente

ext4 ha provato di essere un file system longevo e continuerà ad essere usato ancora estensivamente per molto tempo. Non ho mai avuto particolari problemi nella gestione e uso di file system ext4.

XFS

XFS è un file system a 64 bit journaled sviluppato da Silicon Graphics nel 1993 e tuttora in sviluppo ad esempio da Red Hat che ha deciso di impostarlo di default nel suo sitema operativo orientato alle aziende. XFS è stabile e veloce specialmente per l’accesso parallelo ai file.

Caratteristiche:

• Dimensione massima file system: 8 EiB = 8*1024 PiB = 8*1024*1024 TiB (indirizzamento a 64 bit)
• Struttura contenuto delle cartelle: B+ alberi
• Allocazione dei file: B+ alberi
• Attributi estesi
• I/O diretto con DMA
• Extent
• Journaling
• Allocazione ritardata
• Gruppi di allocazione: il file system viene partizionato in gruppi di allocazione, ogni gruppo di allocazione gestisce i suoi i-node e spazio libero separatamente, questo migliora le prestazioni multithread.
• File sparsi: ogni file ha a disposizione uno spazio di indirizzamento di 64 bit, quindi può contenere buchi che non vengono allocati su disco
• Deframmentazione in linea con xfs_fsr (file system reorganizer)
• Ridimensionamento in linea con xfs_grow solo per aumento delle dimensioni
• Utilità xfsdump e xfsrestore native per backup e ripristino
• Utilità xfs_freeze per bloccare temporaneamente la modifica del file system (utile per fare un backup stile snapshot)

Difetti:

• Non supporta i codici di controllo degli erroi contro la corruzione silenziosa dei dati
• Non supporta la riduzione delle dimensioni del file system in linea, se non tramite un xfsdump e un xfsrestore
• Non supporta sottovolumi e snapshot
• Non supporta la compressione trasparente
• Non supporta la cifratura trasparente

La mia, ancor breve, esperienza con XFS è stata positiva. Sto provando XFS su questo server e devo dire che la differenza in prestazioni rispetto a btrfs è notevole. A difesa di btrfs, visto che supporta la compressione trasparente, su microSD era più veloce di ext4, ma su hard disk XFS lo batte decisamente.

btrfs

Lo sviluppo di btrfs è stato iniziato da Oracle nel 2007, in risposta a ZFS.

btrfs è un file system CoW (Copy on Write), cioè quando si modifica un blocco, invece di attuarla direttamente, il blocco viene copiato con la modifica altrove. Questo approccio porta a molti vantaggi: il journaling non è necessario, i blocchi originali vengono mantenuti e quindi gli snapshot sono implementabili senza perdita di prestazioni. In questo modo, btrfs incorpora le funzionalità di LVM (Logical Volume Manager).

La teoria di btrfs non fa una grinza, purtroppo però in pratica non è tutto così bello. Nella pratica lo sviluppo di btrfs è un po’ rallentato e da un po’ di cicli di kernel vengono mandati solo pochi bug-fix, nonostante btrfs soffra di alcuni problemi e lacune che lo rendono meno fruibile.

Come avevo già detto in un mio [precedente articolo][btrfs], btrfs può essere utile quando si ha a che fare con dispositivi di massa lenti come le microSD, visto che supporta la compressione trasparente, ma su dispositivi più veloci non ne val la pena, perché le prestazioni di questo file system in molti casi sono piuttosto basse. C’è da dire però che almeno supporta i checksum per individuare i dati corrotti e questo può essere una delle cause della perdita di prestazioni rispetto alla concorrenza.

Inoltre mi sono ritrovato a dover risolvere alcuni problemi fastidiosi. Ad esempio lo spazio disponibile viene gestito in modo particolare e capita di ritrovarsi senza spazio pur eliminando i file pesanti non più necessari! Lo spazio libero tornerà disponibile solo dopo una lunga operazione di balance, il che ricorda troppo la deframmentazione dei vecchi tempi.

Caratteristiche:

• Checksum sui dati e metadati
• Deframmentazione in linea
• Ridimensionamento in linea
• Aggiunta e rimozione di dispositivi a blocchi in linea
• RAID 0, 1 e 10
• Compressione trasparente con algoritmi LZO o zlib
• Cloni, la copia di file di grandi dimensioni avviene stile fork POSIX, cioè il file non viene copiato fisicamente, ma viene soltanto aggiunto un nuovo i-node che punta agli stessi blocchi fisici. Quando avviene una modifica su un blocco, grazie al CoW, i due i-node punteranno, uno al blocco originale, l’altro al blocco modificato.
• Sottovolumi, per separare logicamente i dati in modo flessibile
• Snapshot, fotografia di un sottovolume, che viene mantenuta dalla CoW
• btrfs send e receive, 2 tool che permettono di inviare le differenze tra due sottovolumi e riceverle per replicare le stesse modifiche su un sottovolume precedentemente clonato. Questo permette di creare backup incrementali in modo efficiente.
• Conversione dal file system ext4 a btrfs
• Controllo integrità tramite btrfs check
• Deduplicazione dei dati

Difetti:

• prestazioni molto più basse della media, se non per le letture sequenziali
• Non supporta la cifratura trasparente di file e cartelle
• le configurazioni RAID 5 e 6 corrompono i dati!

Purtroppo btrfs promette molte cose, ma per il momento ha ancora troppi bug e il suo sviluppo sembra stia rallentando sempre di più. In definitiva non lo raccomando, a meno che non siate disposti a sacrificare prestazioni e spazio libero in cambio delle funzionalità che offre ovvero snapshot e sottovolumi.

ZFS

Lo sviluppo di ZFS (Zettabyte file system) è stato iniziato da Sun Microsystems nel 2005, con una licenza incompatibile con il kernel Linux, la CDDL, il che lo rende distribuibile solo separatamente dal kernel. Come btrfs, è un file system CoW (Copy on Write). In risposta a ZFS, Oracle aveva iniziato a sviluppare btrfs, ma nonostante l’acquisizione di Sun ha deciso di mandare avanti entrambi i progetti.

Caratteristiche:

• Spazio di indirizzamento a 128 bit (non bastano tutte le memorie sulla terra)
• Checksum dei dati e metadati a 256 bit
• Crittografia trasparente per file e cartelle
• Compressione trasparente
• Deframmentazione in linea
• Ridimensionamento in linea
• Aggiunta e rimozione di dispositivi a blocchi in linea
• Cloni
• Sottovolumi
• Snapshot
• invio e ricezione di sottovolumi
• Deduplicazione dei dati

Svantaggi:

• va distribuito separatamente dal kernel Linux
• uso di RAM elevato

Sicuramente ho tralasciato qualcosa, perché non ho esperienza con ZFS e perché la lista di funzionalità è infinita. Senz’altro un file system valido, ma ovviamente relegato a certi tipi di utilizzo e requisiti. Pur non avendo provato ZFS, credo che i file system CoW non siano ancora pronti ad un uso desktop… o forse sono i desktop a non essere ancora pronti?

Con questo dubbio si conclude l’articolo, ma non ciò che posso raccontarvi. A presto!

[btrfs]: {{< ref “/blog/aumentare-le-prestazioni-con-btrfs.md” >}}