La maggior parte delle moderne distribuzioni Linux ha per impostazione predefinita il filesystem ext4, proprio come le precedenti distribuzioni Linux avevano per impostazione predefinita ext3, ext2 e, se torni abbastanza indietro, ext.
Se sei nuovo di Linux, o di filesystem, potresti chiederti cosa porta ext4 al tavolo che ext3 non ha. Potresti anche chiederti se ext4 sia ancora in fase di sviluppo attivo, date le raffiche di notizie di filesystem alternativi come btrfs, xfs e zfs.
Più risorse Linux
- Comandi Linux cheat sheet
- Cheat sheet sui comandi avanzati di Linux
- Corso online gratuito:Panoramica tecnica RHEL
- Cheat sheet della rete Linux
- Cheat sheet di SELinux
- Cheat sheet dei comandi comuni di Linux
- Cosa sono i container Linux?
- I nostri ultimi articoli su Linux
Non possiamo coprire tutto ciò che riguarda i filesystem in un solo articolo, ma cercheremo di aggiornarti sulla cronologia del filesystem predefinito di Linux, dove si trova e cosa aspettarti.
Durante la preparazione di questa panoramica, ho attinto molto dai vari articoli del filesystem ext di Wikipedia, dalle voci wiki di kernel.org su ext4 e dalle mie esperienze.
Una breve storia di ext
Filesystem MINIX
Prima che esistesse ext, c'era il filesystem MINIX. Se non sei aggiornato sulla tua cronologia di Linux, MINIX era un sistema operativo molto piccolo simile a Unix per microcomputer IBM PC/AT. Andrew Tannenbaum lo ha sviluppato per scopi didattici e ha rilasciato il suo codice sorgente (in forma cartacea!) nel 1987.
Sebbene tu possa esaminare il codice sorgente di MINIX, in realtà non era un software gratuito e open source (FOSS). Gli editori del libro di Tannebaum richiedevano un canone di $ 69 per far funzionare MINIX, che era incluso nel costo del libro. Tuttavia, questo era incredibilmente poco costoso per l'epoca e l'adozione di MINIX decollò rapidamente, superando presto l'intento originale di Tannenbaum di usarlo semplicemente per insegnare la codifica dei sistemi operativi. Nel corso degli anni '90, potresti trovare installazioni MINIX fiorenti nelle università di tutto il mondo e un giovane Linus Torvalds ha utilizzato MINIX per sviluppare il kernel Linux originale, annunciato per la prima volta nel 1991 e rilasciato sotto licenza GPL nel dicembre 1992.
Ma aspetta, questo è un filesystem articolo, giusto? Sì, e MINIX aveva il suo filesystem, su cui si basavano anche le prime versioni di Linux. Come MINIX, potrebbe essere descritto in modo non caritatevole come un esempio "giocattolo" del suo genere:il filesystem MINIX potrebbe gestire nomi di file fino a 14 caratteri e indirizzare solo 64 MB di spazio di archiviazione. Nel 1991, il disco rigido tipico aveva già una dimensione di 40-140 MB. Linux aveva chiaramente bisogno di un filesystem migliore!
est
Mentre Linus ha hackerato il nascente kernel Linux, Rémy Card ha lavorato sul primo filesystem ext. Implementato per la prima volta nel 1992, solo un anno dopo l'annuncio iniziale di Linux stesso!, ext ha risolto il peggiore dei problemi del filesystem MINIX.
L'ext del 1992 utilizzava il nuovo livello di astrazione del filesystem virtuale (VFS) nel kernel Linux. A differenza del precedente filesystem MINIX, ext poteva indirizzare fino a 2 GB di spazio di archiviazione e gestire nomi di file di 255 caratteri.
Ma ext non ha avuto un lungo regno, in gran parte a causa del suo timestamp primitivo (solo un timestamp per file, anziché i tre timbri separati per la creazione di inode, l'accesso ai file e la modifica dei file che conosciamo oggi). Solo un anno dopo, ext2 pranzò.
est2
Rémy ha chiaramente realizzato i limiti di ext abbastanza rapidamente, dal momento che ha progettato ext2 come sostituto un anno dopo. Mentre ext aveva ancora le sue radici nei sistemi operativi "giocattolo", ext2 è stato progettato fin dall'inizio come un filesystem di livello commerciale, seguendo gli stessi principi del Berkeley Fast File System di BSD.
Ext2 offriva le dimensioni massime dei file nei gigabyte e le dimensioni del filesystem nei terabyte, posizionandolo saldamente nei grandi campionati per gli anni '90. È stato adottato rapidamente e ampiamente, sia nel kernel Linux che infine in MINIX, nonché da moduli di terze parti che lo hanno reso disponibile per MacOS e Windows.
C'erano ancora problemi da risolvere, tuttavia:i filesystem ext2, come la maggior parte dei filesystem degli anni '90, erano soggetti a una corruzione catastrofica se il sistema si arrestava in modo anomalo o perdeva energia durante la scrittura dei dati sul disco. Hanno anche subito significative perdite di prestazioni dovute alla frammentazione (l'archiviazione di un singolo file in più posizioni, fisicamente sparpagliato su un disco rotante) con il passare del tempo.
Nonostante questi problemi, ext2 è ancora oggi utilizzato in alcuni casi isolati, più comunemente come formato per chiavette USB portatili.
est3
Nel 1998, sei anni dopo l'adozione di ext2, Stephen Tweedie annunciò che stava lavorando per migliorarlo in modo significativo. Questo è diventato ext3, che è stato adottato nella linea principale di Linux con la versione del kernel 2.4.15, nel novembre 2001.
Ext2 aveva funzionato molto bene con le distribuzioni Linux per la maggior parte, ma, come FAT, FAT32, HFS e altri filesystem dell'epoca, era soggetto a una corruzione catastrofica durante la perdita di alimentazione. Se si perde potenza durante la scrittura di dati nel filesystem, è possibile che vengano lasciati in quello che viene chiamato un incoerente stato:uno in cui le cose sono state lasciate a metà e per metà annullate. Ciò può comportare la perdita o il danneggiamento di vaste porzioni di file non correlate a quello salvato o addirittura la non montabilità dell'intero filesystem.
Ext3 e altri filesystem della fine degli anni '90, come NTFS di Microsoft, utilizzano journaling risolvere questo problema. Il journal è un'allocazione speciale su disco in cui le scritture vengono archiviate nelle transazioni; se la transazione termina la scrittura su disco, i suoi dati nel giornale vengono impegnati al filesystem stesso. Se il sistema si arresta in modo anomalo prima che l'operazione venga eseguita, il sistema appena riavviato la riconosce come transazione incompleta e la ripristina come se non fosse mai avvenuta. Ciò significa che il file su cui si sta lavorando potrebbe ancora andare perso, ma il filesystem stesso rimane coerente e tutti gli altri dati sono al sicuro. Sono disponibili tre livelli di journaling nell'implementazione del kernel Linux di ext3:journal , ordinato e storno .
- Diario è la modalità a rischio più basso, scrivendo sia i dati che i metadati nel diario prima di eseguirne il commit nel filesystem. Ciò garantisce la coerenza del file su cui viene scritto, così come del filesystem nel suo insieme, ma può ridurre significativamente le prestazioni.
- Ordinato è la modalità predefinita nella maggior parte delle distribuzioni Linux; la modalità ordinata scrive i metadati nel journal ma esegue il commit dei dati direttamente nel filesystem. Come suggerisce il nome, l'ordine delle operazioni qui è rigido:in primo luogo, i metadati vengono salvati nel journal; secondo, i dati vengono scritti nel filesystem e solo allora i metadati associati nel journal vengono scaricati nel filesystem stesso. Ciò garantisce che, in caso di arresto anomalo, i metadati associati alle scritture incomplete siano ancora nel diario e il filesystem possa disinfettare quelle scritture incomplete durante il rollback del diario. In modalità ordinata, un arresto anomalo può causare il danneggiamento del file o dei file su cui vengono scritti attivamente durante l'arresto anomalo, ma il file system stesso e i file su cui non vengono scritti attivamente sono garantiti al sicuro.
- Ritorno è la terza e meno sicura modalità di journaling. In modalità writeback, come la modalità ordinata, i metadati vengono inseriti nel journal, ma non i dati. A differenza della modalità ordinata, sia i metadati che i dati possono essere scritti in qualsiasi ordine abbia senso per ottenere le migliori prestazioni. Questo può offrire aumenti significativi delle prestazioni, ma è molto meno sicuro. Sebbene la modalità writeback offra ancora una garanzia di sicurezza per il filesystem stesso, i file che sono stati scritti durante o prima dell'arresto anomalo sono vulnerabili a perdite o danneggiamenti.
Come ext2 prima, ext3 utilizza l'indirizzamento interno a 16 bit. Ciò significa che con una dimensione del blocco di 4K, la dimensione del file più grande che può gestire è 2 TiB in una dimensione massima del filesystem di 16 TiB.
est4
Theodore Ts'o (che a quel tempo era il principale sviluppatore di ext3) ha annunciato ext4 nel 2006, ed è stato aggiunto alla linea principale di Linux due anni dopo, nella versione del kernel 2.6.28. Ts'o descrive ext4 come una tecnologia provvisoria che estende significativamente ext3 ma fa ancora affidamento sulla vecchia tecnologia. Si aspetta che alla fine venga soppiantato da un vero filesystem di nuova generazione.
Ext4 è funzionalmente molto simile a ext3, ma offre supporto per filesystem di grandi dimensioni, maggiore resistenza alla frammentazione, prestazioni più elevate e timestamp migliorati.
Est4 vs est3
Ext3 ed ext4 presentano alcune differenze molto specifiche, su cui mi concentrerò qui.
Compatibilità con le versioni precedenti
Ext4 è stato specificamente progettato per essere il più compatibile possibile con ext3. Questo non solo consente di aggiornare i filesystem ext3 sul posto a ext4; consente inoltre al driver ext4 di montare automaticamente i filesystem ext3 in modalità ext3, rendendo superfluo mantenere le due basi di codice separatamente.
Filesystem di grandi dimensioni
I filesystem Ext3 utilizzavano l'indirizzamento a 32 bit, limitandoli a 2 file TiB e 16 filesystem TiB (supponendo una dimensione del blocco di 4 KiB; alcuni filesystem ext3 utilizzano dimensioni del blocco più piccole e quindi sono ulteriormente limitate).
Ext4 utilizza l'indirizzamento interno a 48 bit, rendendo teoricamente possibile allocare file fino a 16 TiB su filesystem fino a 1.000.000 TiB (1 EiB). Le prime implementazioni di ext4 erano ancora limitate a 16 filesystem TiB da alcune utility userland, ma a partire dal 2011 e2fsprogs ha supportato direttamente la creazione di filesystem>16TiB ext4. Ad esempio, Red Hat Enterprise Linux supporta contrattualmente filesystem ext4 fino a 50 TiB e consiglia volumi ext4 non superiori a 100 TiB.
Miglioramenti allocazione
Ext4 introduce molti miglioramenti nel modo in cui i blocchi di archiviazione vengono allocati prima di scriverli su disco, il che può aumentare significativamente le prestazioni sia in lettura che in scrittura.
Estensioni
Un'estensione è un intervallo di blocchi fisici contigui (fino a 128 MiB, supponendo una dimensione del blocco di 4 KiB) che possono essere riservati e indirizzati contemporaneamente. L'utilizzo delle estensioni riduce il numero di inode richiesti da un determinato file e riduce notevolmente la frammentazione e aumenta le prestazioni durante la scrittura di file di grandi dimensioni.
Assegnazione multiblocco
Ext3 ha chiamato il suo allocatore di blocchi una volta per ogni nuovo blocco allocato. Ciò potrebbe facilmente comportare una forte frammentazione quando più writer sono aperti contemporaneamente. Tuttavia, ext4 utilizza l'allocazione ritardata, che gli consente di unire le scritture e prendere decisioni migliori su come allocare i blocchi per le scritture di cui non ha ancora eseguito il commit.
Pre-assegnazione persistente
Durante la preallocazione dello spazio su disco per un file, la maggior parte dei file system deve scrivere zero sui blocchi per quel file al momento della creazione. Ext4 consente l'uso di fallocate() invece, che garantisce la disponibilità dello spazio (e tenta di trovare spazio attiguo per esso) senza prima aver bisogno di scrivergli. Ciò aumenta significativamente le prestazioni sia nelle scritture che nelle letture future dei dati scritti per lo streaming e le applicazioni di database.
Assegnazione ritardata
Questa è una caratteristica gommosa e controversa. L'allocazione ritardata consente a ext4 di attendere per allocare i blocchi effettivi in cui scriverà i dati fino a quando non sarà pronto per eseguire il commit dei dati su disco. (Al contrario, ext3 allocherebbe i blocchi immediatamente, anche mentre i dati stavano ancora scorrendo in una cache di scrittura.)
Ritardare l'allocazione dei blocchi quando i dati si accumulano nella cache consente al filesystem di fare scelte più sane su come allocare quei blocchi, riducendo la frammentazione (scrittura e, successivamente, lettura) e aumentando significativamente le prestazioni. Sfortunatamente, aumenta la potenziale perdita di dati nei programmi che non sono stati scritti in modo specifico per chiamare fsync() quando il programmatore vuole assicurarsi che i dati siano stati scaricati completamente sul disco.
Diciamo che un programma riscrive interamente un file:
fd=open("file" ,O_TRUNC); write(fd, data); close(fd);
Con filesystem legacy, close(fd); è sufficiente a garantire che il contenuto di file verrà scaricato su disco. Anche se la scrittura non è, in senso stretto, transazionale, c'è pochissimo rischio di perdere i dati se si verifica un arresto anomalo dopo il file è chiuso.
Se la scrittura non riesce (a causa di errori nel programma, errori sul disco, perdita di alimentazione, ecc.), sia la versione originale che la versione più recente del file potrebbe essere persa o danneggiata. Se altri processi accedono al file mentre viene scritto, vedranno una versione danneggiata. E se altri processi hanno il file aperto e non si aspettano che il suo contenuto cambi, ad esempio una libreria condivisa mappata su più programmi in esecuzione, potrebbero bloccarsi.
Per evitare questi problemi, alcuni programmatori evitano di usare O_TRUNC affatto. Invece, potrebbero scrivere su un nuovo file, chiuderlo, quindi rinominarlo su quello vecchio:
fd=open("newfile"); write(fd, data); close(fd); rename("newfile", "file");
Sotto filesystem senza allocazione ritardata, questo è sufficiente per evitare i potenziali problemi di danneggiamento e crash descritti sopra:Poiché rename() è un'operazione atomica, non verrà interrotta da un crash; e i programmi in esecuzione continueranno a fare riferimento alla vecchia versione non collegata di file fintanto che hanno un filehandle aperto. Ma poiché l'allocazione ritardata di ext4 può causare il ritardo e il riordino delle scritture, rename("newfile","file") può essere effettuato prima il contenuto di newfile sono effettivamente scritti su disco, il che apre il problema dei processi paralleli che ottengono versioni errate di file tutto da capo.
Per mitigare ciò, il kernel Linux (dalla versione 2.6.30) tenta di rilevare questi casi di codice comuni e forzare l'allocazione immediata dei file in questione. Ciò riduce, ma non previene, la potenziale perdita di dati e non aiuta affatto con i nuovi file. Se sei uno sviluppatore, prendi nota:solo un modo per garantire che i dati vengano scritti immediatamente sul disco è chiamare fsync() in modo appropriato.
Sottodirectory illimitate
Ext3 era limitato a un totale di 32.000 sottodirectory; ext4 consente un numero illimitato. A partire dal kernel 2.6.23, ext4 utilizza gli indici HTree per mitigare la perdita di prestazioni con un numero enorme di sottodirectory.
Checksum del diario
Ext3 non ha eseguito il checksum dei suoi journal, che presentavano problemi per i dispositivi disco o controller con cache proprie, al di fuori del controllo diretto del kernel. Se un controller o un disco con la propria cache scrive in modo errato, potrebbe interrompere l'ordine delle transazioni di journaling di ext3, danneggiando potenzialmente i file scritti durante (o per un po' di tempo prima) un arresto anomalo.
In teoria, questo problema viene risolto dall'uso di barriere di scrittura:quando si monta il filesystem, si imposta barrier=1 nelle opzioni di montaggio e il dispositivo rispetterà fsync() chiama fino al metallo. In pratica, è stato scoperto che i dispositivi di archiviazione e i controller spesso non rispetta le barriere di scrittura, migliorando le prestazioni (e i benchmark, rispetto ai concorrenti) ma aprendo la possibilità di un danneggiamento dei dati che avrebbe dovuto essere prevenuto.
Il checksum del journal consente al filesystem di rendersi conto che alcune delle sue voci non sono valide o non sono in ordine al primo montaggio dopo un arresto anomalo. In questo modo si evita l'errore di annullare le voci del diario parziali o non ordinate e di danneggiare ulteriormente il filesystem, anche se i dispositivi di archiviazione mentono e non rispettano le barriere.
Controlli veloci del filesystem
In ext3, l'intero filesystem, inclusi i file eliminati e vuoti, richiedeva il controllo quando fsck viene invocato. Al contrario, ext4 contrassegna blocchi e sezioni non allocati della tabella degli inode come tali, consentendo fsck per saltarli del tutto. Questo riduce notevolmente il tempo per eseguire fsck sulla maggior parte dei filesystem ed è stato implementato dal kernel 2.6.24.
Timestamp migliorati
Ext3 ha offerto timestamp granulari a un secondo. Sebbene sufficienti per la maggior parte degli usi, le applicazioni mission-critical sono spesso alla ricerca di un controllo del tempo molto, molto più stretto. Ext4 si rende disponibile per quelle applicazioni aziendali, scientifiche e mission-critical offrendo timestamp nei nanosecondi.
Inoltre, i filesystem Ext3 non fornivano bit sufficienti per memorizzare le date oltre il 18 gennaio 2038. Ext4 aggiunge altri due bit qui, estendendo l'epoca Unix di altri 408 anni. Se stai leggendo questo nel 2446 d.C., spero che tu sia già passato a un filesystem migliore, ma mi renderà postumo molto, molto felice se stai ancora misurando il tempo dalle 00:00 UTC, 1 gennaio 1970.
Deframmentazione in linea
Né ext2 né ext3 supportavano direttamente la deframmentazione online, ovvero la deframmentazione del filesystem mentre era montato. Ext2 aveva un'utilità inclusa, e2defrag , ha fatto ciò che suggerisce il nome, ma doveva essere eseguito offline mentre il filesystem non era montato. (Questo è, ovviamente, particolarmente problematico per un filesystem di root.) La situazione era anche peggiore in ext3, anche se ext3 aveva molte meno probabilità di soffrire di una grave frammentazione rispetto a ext2, eseguendo e2defrag contro un filesystem ext3 potrebbe causare un danneggiamento catastrofico e la perdita di dati.
Sebbene ext3 fosse originariamente ritenuto "non influenzato dalla frammentazione", i processi che impiegano processi di scrittura massicciamente paralleli sullo stesso file (ad es. BitTorrent) hanno chiarito che non era del tutto vero. Diversi hack e soluzioni alternative allo spazio utente, come Shake, hanno risolto questo problema in un modo o nell'altro, ma erano più lenti e in vari modi meno soddisfacenti di un vero processo di deframmentazione a livello di kernel, sensibile al filesystem.
Ext4 risolve questo problema con e4defrag , un'utilità di deframmentazione online, in modalità kernel, sensibile al filesystem, a livello di blocco e di estensione.
Sviluppo ext4 in corso
Ext4 è, come Monty Python la vittima della peste una volta disse:"non è ancora del tutto morta!" Sebbene il suo sviluppatore principale lo consideri un semplice tappabuchi lungo la strada verso un filesystem veramente di nuova generazione, nessuno dei probabili candidati sarà pronto (a causa di problemi tecnici o di licenza) per l'implementazione come filesystem root ancora per un po' di tempo.
Ci sono ancora alcune funzionalità chiave in fase di sviluppo nelle versioni future di ext4, tra cui il checksum dei metadati, il supporto delle quote di prima classe e blocchi di allocazione di grandi dimensioni.
Checksum dei metadati
Poiché ext4 ha superblocchi ridondanti, il checksum dei metadati al loro interno offre al filesystem un modo per capire da solo se il superblocco primario è danneggiato e deve utilizzare un'alternativa. È possibile eseguire il ripristino da un superblocco danneggiato senza checksum, ma l'utente dovrebbe prima rendersi conto che era danneggiato, quindi provare a montare manualmente il filesystem utilizzando un'alternativa. Poiché il montaggio di un filesystem in lettura e scrittura con un superblocco primario corrotto può, in alcuni casi, causare ulteriori danni, questa non è una soluzione sufficiente, anche con un utente sufficientemente esperto!
Rispetto al checksum per blocco estremamente robusto offerto dai filesystem di nuova generazione come btrfs o zfs, il checksum dei metadati di ext4 è una caratteristica piuttosto debole. Ma è molto meglio di niente.
Anche se suona come un gioco da ragazzi - sì, checksum TUTTE LE COSE! - ci sono alcune sfide significative per inserire i checksum in un filesystem dopo il fatto; vedere il documento di progettazione per i dettagli grintosi.
Supporto per le quote di prima classe
Aspetta, quote?! Li abbiamo dai giorni ext2! Sì, ma sono sempre stati un ripensamento e hanno sempre fatto schifo. Probabilmente non vale la pena di entrare nei dettagli pelosi qui, ma il documento di progettazione illustra i modi in cui le quote verranno spostate dallo spazio utente al kernel e applicate in modo più corretto e performante.
Blocchi di allocazione di grandi dimensioni
Col passare del tempo, quei fastidiosi sistemi di archiviazione continuano a diventare sempre più grandi. Con alcune unità a stato solido che utilizzano già blocchi hardware 8K, l'attuale limitazione di ext4 ai blocchi 4K diventa sempre più limitante. Blocchi di archiviazione più grandi possono ridurre la frammentazione e aumentare significativamente le prestazioni, a scapito di un maggiore spazio "slack" (lo spazio rimasto quando è necessaria solo una parte di un blocco per archiviare un file o l'ultimo pezzo di un file).
Puoi visualizzare i dettagli pelosi nel documento di progettazione.
Limitazioni pratiche di ext4
Ext4 è un filesystem robusto e stabile, ed è ciò che la maggior parte delle persone dovrebbe probabilmente utilizzare come filesystem di root nel 2018. Ma non può gestire tutto. Parliamo brevemente di alcune delle cose che non dovresti aspettati da ext4, ora o probabilmente in futuro.
Sebbene ext4 possa indirizzare fino a 1 EiB, equivalente a 1.000.000 di TiB, di dati, tu davvero, davvero non dovrebbe provare a farlo. Ci sono problemi di scala al di là della semplice capacità di ricordare gli indirizzi di molti più blocchi, ed ext4 ora (e probabilmente non lo farà mai) scala molto bene oltre 50-100 TiB di dati.
Ext4 inoltre non fa abbastanza per garantire l'integrità dei tuoi dati. Per quanto il grande progresso sia stato il journaling nei giorni ext3, non copre molte delle cause comuni di danneggiamento dei dati. Se i dati sono danneggiati mentre sono già sul disco, a causa di hardware difettoso, impatto dei raggi cosmici (sì, davvero) o semplice degrado dei dati nel tempo, ext4 non ha modo né di rilevare né di riparare tale danneggiamento.
Basandosi sugli ultimi due elementi, ext4 è solo un puro filesystem e non un gestore del volume di archiviazione. Ciò significa che anche se hai più dischi, e quindi parità o ridondanza, da cui potresti teoricamente recuperare dati corrotti, ext4 non ha modo di saperlo o di usarlo a tuo vantaggio. Mentre è teoricamente possibile separare un filesystem e un sistema di gestione del volume di archiviazione in livelli discreti senza perdere le funzionalità di rilevamento automatico del danneggiamento e riparazione, non è così che sono progettati gli attuali sistemi di archiviazione e presenterebbe sfide significative ai nuovi progetti.
Filesystem alternativi
Prima di iniziare, un avvertimento:sii molto attenzione con qualsiasi filesystem alternativo che non sia integrato in e direttamente supportato come parte del kernel principale della tua distribuzione!
Anche se un filesystem è sicuro , usarlo come filesystem di root può essere assolutamente terrificante se si verifica un singhiozzo durante l'aggiornamento del kernel. Se non sei estremamente a tuo agio con l'idea di eseguire l'avvio da un supporto alternativo e cercare manualmente e pazientemente i moduli del kernel, le configurazioni di grub e DKMS da un chroot... non uscire dalla prenotazione con il filesystem di root su un sistema che ti interessa.
Potrebbero esserci buone ragioni per usare un filesystem che la tua distribuzione non supporta direttamente, ma se lo fai, ti consiglio vivamente di montarlo dopo il sistema è attivo e utilizzabile. (Ad esempio, potresti avere un filesystem root ext4, ma memorizzare la maggior parte dei tuoi dati su un pool zfs o btrfs.)
XFS
XFS è la linea principale di un filesystem non ext sotto Linux. È un filesystem di journaling a 64 bit che è stato integrato nel kernel Linux dal 2001 e offre prestazioni elevate per filesystem di grandi dimensioni e livelli elevati di concorrenza (ovvero, un numero davvero elevato di processi che scrivono tutti nel filesystem contemporaneamente).
XFS è diventato il filesystem predefinito per Red Hat Enterprise Linux, a partire da RHEL 7. Presenta ancora alcuni svantaggi per gli utenti domestici o di piccole imprese, in particolare, è una vera seccatura ridimensionare un filesystem XFS esistente, al punto che di solito fa di più senso per crearne un altro e copiare i tuoi dati.
Sebbene XFS sia stabile e performante, non c'è abbastanza differenza concreta nell'uso finale tra esso ed ext4 per consigliarne l'uso ovunque non sia l'impostazione predefinita (ad es. RHEL7) a meno che risolve un problema specifico che stai riscontrando con ext4, come filesystem con capacità>50 TiB.
XFS non è in alcun modo un filesystem di "prossima generazione" nel modo in cui lo sono ZFS, btrfs o persino WAFL (un filesystem SAN proprietario). Come ext4, molto probabilmente dovrebbe essere considerato un ripiego lungo la strada verso qualcosa di meglio.
ZFS
ZFS è stato sviluppato da Sun Microsystems e prende il nome dallo zettabyte, equivalente a 1 trilione di gigabyte, in quanto potrebbe teoricamente indirizzare sistemi di storage così grandi.
Un vero filesystem di nuova generazione, ZFS offre la gestione dei volumi (la capacità di indirizzare più dispositivi di archiviazione individuali in un unico filesystem), il checksum crittografico a livello di blocco (consentendo il rilevamento della corruzione dei dati con un tasso di precisione estremamente elevato), la riparazione automatica della corruzione (dove è disponibile lo storage ridondante o di parità), la replica incrementale asincrona rapida, la compressione inline e altro ancora. Molto di più.
Il problema più grande con ZFS, dal punto di vista di un utente Linux, è la licenza. ZFS è stato concesso in licenza CDDL, che è una licenza semi-permissiva che è in conflitto con la GPL. Ci sono molte polemiche sulle implicazioni dell'uso di ZFS con il kernel Linux, con opinioni che vanno da "è una violazione della GPL" a "è una violazione del CDDL" a "va benissimo, semplicemente non è stato testato in tribunale. " In particolare, Canonical ha incluso il codice ZFS in linea nei suoi kernel predefiniti dal 2016 senza contestazioni legali finora.
In questo momento, anche da molto io stesso avido utente ZFS, non consiglierei ZFS come filesystem di root Linux. Se vuoi sfruttare i vantaggi di ZFS su Linux, configura un piccolo filesystem root su ext4, quindi metti ZFS nello spazio di archiviazione rimanente e inserisci dati, applicazioni, qualunque cosa ti piaccia, ma mantieni il root su ext4, fino alla tua distribuzione esplicitamente
btrfs
Btrfs, abbreviazione di B-Tree Filesystem e solitamente pronunciato "burro", è stato annunciato da Chris Mason nel 2007 durante il suo incarico in Oracle. Btrfs mira alla maggior parte degli stessi obiettivi di ZFS, offrendo gestione di più dispositivi, checksum per blocco, replica asincrona, compressione inline e altro ancora.
A partire dal 2018, btrfs è ragionevolmente stabile e utilizzabile come filesystem standard a disco singolo, ma probabilmente non dovrebbe essere utilizzato come gestore di volumi. Soffre di problemi di prestazioni significativi rispetto a ext4, XFS o ZFS in molti casi d'uso comuni e le sue funzionalità di nuova generazione (replicazione, topologie a più dischi e gestione degli snapshot) possono essere piuttosto difettose, con risultati che vanno da prestazioni catastroficamente ridotte all'effettiva perdita di dati.
Lo stato attuale dei btrfs è controverso; SUSE Enterprise Linux lo ha adottato come filesystem predefinito nel 2015, mentre Red Hat ha annunciato che non avrebbe più supportato btrfs a partire da RHEL 7.4 nel 2017. Probabilmente vale la pena notare che la produzione, le distribuzioni supportate di btrfs lo utilizzano come filesystem a disco singolo, non come gestore di volumi di più dischi a la ZFS, anche Synology, che utilizza btrfs sui suoi dispositivi di archiviazione, ma lo sovrappone al RAID kernel Linux convenzionale (mdraid) per gestire i dischi.