|
|
<- SL: Postfix - Copertina - SL: Protocolli -> |
|
Sistemi Liberi
di Mano
L'articolo...Illustra le caratteristiche dei filesystem di tipo journaled, ed i vantaggi rispetto a quelli tradizionali in robustezza e integrità dei dati. Presenta poi i filesystem journaled disponibili per GNU/Linux, fornendo in appendice istruzioni sulla loro installazione e configurazione. |
Immaginate una qualsiasi sera di tempesta, in una qualsiasi cittadina. State lavorando duramente per finire un compito urgentissimo per il quale siete in solenne ritardo, quando il Fato o chi per esso si ricorda improvvisamente di voi, e giudica che le cose vi stanno andando decisamente troppo bene; rischiate di dimenticarvi che esiste la Legge di Murphy, e a quel punto decide di mantenervi in allenamento creando un simpatico sbalzo di tensione sulla linea. Vi trovate a fissare così uno schermo nero, che lascia presto il posto alla schermata del BIOS, e per l'incredulità vi dimenticate anche di fermare le mani che stanno ancora scrivendo...
Alzi la mano chi non ha mai provato una situazione simile, e questo è solo uno dei tanti casi che possono accadere! Nonostante la vostra macchina GNU/Linux (NB: d'ora in avanti ci si riferirà al sistema "GNU/Linux" semplicemente come "Linux", per motivi di brevità, senza che per questo il senso cambi ;) preferita possa rimanere operativa a tempo indeterminato, di fatto gli imprevisti sono sempre in agguato: vostra madre/moglie accende il microonde, il frullatore e la piastra per i capelli assieme e fa "saltare le valvole", il bimbo decide di vedere cosa succede a premere quel bel bottone rosso sul frontalino del vostro fido PC, o più semplicemente incontrate un programma particolarmente pesante che vi inchioda tutto il sistema... oddio, è vero, se usate Linux probabilmente starete cercando disperatamente di ricordare l'ultima volta in cui è successo, ma chi usa altri sistemi operativi un po' meno stabili sa benissimo di cosa si tratta! Comunque, a questo punto l'unica cosa da fare è semplice: riavviare. Probabilmente l'hardware non ha subito nessun danno, non è così delicato, ma purtroppo non è solo questo il punto!
Il problema grosso è che i vari filesystem presenti nelle partizioni dei vostri dichi rigidi non sono stati smontati in maniera pulita. Un filesystem al suo interno mantiene non solo i file veri e propri, ma anche altri dati, i cosidetti metadata, che registrano tutte le informazioni che riguardano i file: grandezza, collocazione fisica sul supporto, eccetera. Ogni volta che si crea, modifica o cancella un file (o una directory) il sistema deve aggiornare i metadata, così da mantenerli sempre allineati ai dati immagazzinati nei file. Il problema è che questo implica una certa quantità di accessi fisici al disco, che viene compiuta in un tempo relativamente lungo. Se al momento dell'interruzione del sistema stavate scrivendo qualcosa sul disco, e poiché di solito questi eventi capitano in condizioni di particolare carico questa non è un'eventualità tanto remota, è probabile che una di queste operazioni si sia interrotta a metà. Si ha allora un disallineamento tra quanto è stato scritto su disco e i metadata che dovrebbero localizzarlo. Il sistema operativo allora deve controllare tutto il disco alla ricerca di questi disallineamenti, e tentare di correggerli.
Nella pratica questo si risolve nel famoso/famigerato messaggio "Filesystem on /dev/xdxX was not cleanly unmounted, running fsck..." che si presenta al riavvio; la sequenza di boot viene bloccata per tutto il tempo necessario per controllare i dischi che erano montati quando è accaduto il fattaccio e, viste le dimensioni degli hard disk odierni, non ci si può obiettivamente aspettare un tempo breve! La cosa costituisce già una bella seccatura, ma c'è un aspetto ben peggiore: in alcuni casi il disallineamento è semplicemente troppo grave per poter essere corretto, oppure mancano del tutto alcuni parametri essenziali al ripristino, e il filesystem non può trovarli da solo. I dati che si stavano scrivendo vengono allora semplicemente persi, e c'è ben poco da fare per recuperarli. Questo fatto da solo può quindi significare una grossissima perdita, a livello di informazioni, di tempo e di denaro; purtroppo, a tutti è capitato almeno una volta di veder vanificato un lungo e delicato lavoro per un momento di distrazione, o per ragioni del tutto esterne; è frustrante, ma soprattutto costituisce un reale danno.
Le soluzioni di solito sono affidate alla prevenzione, e al buonsenso di ognuno: salvare spesso, e fare il backup periodico dei dati rilevanti. Tuttavia, anche queste soluzioni non offrono un totale grado di sicurezza; l'ideale, evidentemente, sarebbe un filesystem strutturato in maniera molto più robusta, in grado di prevenire alla radice tale tipo di problema. Ebbene, un siffatto filesystem esiste, anzi ne esistono molti, e questo articolo si occuperà proprio di presentare queste soluzioni, per quanto riguarda il mondo Linux.
Immaginate ad esempio un uomo che sta svolgendo tranquillo le sue attività normali. Ad un certo punto, per cause che possono essere le più diverse, riceve una solenne botta in testa, sviene, e al risveglio non ricorda più nulla delle ore precedenti al trauma. Per di più si trova in un grosso stato confusionale; dovrà trascorrere molte ore cercando di riannodare i fili della sua mente, e non è neppure detto che ci riesca se i buchi nella sua memoria saranno troppo importanti. È insomma in una situazione molto vicina a quello che succede a un sistema che venga bruscamente interrotto nella sua attività: anche lui dovrà "riannodare i fili" dei dati in cui riscontra inconsistenze, ed anche lui affronterà gli stessi problemi e le stesse lungaggini. A questo punto immaginate però che l'uomo abbia la lodevole abitudine di tenere un diario di ogni azione da lui compiuta; gli basterà allora rileggere le ultime pagine del diario per sapere tutto ciò che ha fatto e che è, in breve tempo e senza possibilità di errore!
Questo è esattamente quello che fanno i filesystem di questo tipo, denominati filesystem journaled: mantengono al loro interno un file speciale che agisce da diario (in inglese journal, appunto), dove registrano tutti i cambiamenti che vengono fatti a file e metadata. In questo modo, anche se tali cambiamenti non vengono poi fisicamente applicati, il filesystem ha comunque tutte le informazioni necessarie per riparare i disallineamenti.
La soluzione, insomma, è semplice: in questo modo si risolvono in un solo colpo entrambi i problemi che abbiamo individuato poc'anzi, rendendo l'attesa al reboot molto breve (nella maggior parte dei casi di soli pochi secondi, indipendentemente dalla dimensione del supporto), e soprattutto garantendo in misura molto maggiore la sicurezza dei dati, che ben difficilmente subiranno danni. In alcuni casi potranno andare perduti gli ultimissimi dati scritti, quelli che non avevano fatto in tempo ad essere scritti fisicamente su disco, ma non vi sarà rischio di ritrovarsi file corrotti, e questo è decisamente molto importante.
D'altro canto, per avere queste caratteristiche notevoli si paga un prezzo: il file di journal occupa un certo spazio su disco, quindi lo spazio d'immagazzinamento totale sarà minore che utilizzando altri filesystem. Inoltre, l'aggiornamento continuo del journal impiega tempo, e questo implica una generale lentezza delle operazioni: i filesystem journaled saranno più lenti rispetto ai loro colleghi non-journaled. Ovviamente, sta all'utente finale stabilire se e quanto questi aspetti negativi annullino i vantaggi di cui abbiamo parlato; dipende dal contesto in cui si opera, dal valore dei dati che si immagazzinano, dal rischio effettivo che corrono, e così via. Del resto, è sempre possibile creare soluzioni ibride, con partizioni "di lavoro" che utilizzano un filesystem normale, e partizioni "d'immagazzinamento" che ne utilizzano uno journaled; l'ideale insomma è aver la possibilità di scegliere tra entrambe le soluzioni in modo semplice e quanto più trasparente possibile, e per fortuna le cose si stanno muovendo proprio in questa direzione!
Tradizionalmente, il filesystem principe per Linux è l'Ext2. Si tratta di un filesystem efficiente e veloce, che nel corso degli anni ha dimostrato di essere in grado (con i dovuti miglioramenti di cui ha goduto) di tenere il passo della tecnologia. Questo filesystem non è però journaled, e infatti i problemi che sono causati da un arresto forzato del sistema sono tristemente noti. Dalla parte opposta, l'esigenza di avere un sistema di immagazzinamento dei dati che garantisca la massima affidabilità e velocità si è fatta via via più pressante man mano che Linux ha assunto un ruolo di primo piano anche nell'industria, oltre che presso l'utenza aziendale e casalinga. La natura aperta di questo sistema operativo da sempre ha facilitato l'integrazione di nuove caratteristiche man mano che se ne sentiva il bisogno: era quindi solo questione di tempo. Per la verità, da parecchio tempo la comunità opensource da una parte e alcune grosse firme dall'altra avevano cominciato a lavorare per colmare questa lacuna, ma solo di recente questi progetti hanno raggiunto la piena maturazione. Esamineremo qui le quattro principali soluzioni che sono state sviluppate, e cercheremo di dare anche le istruzioni pratiche per rendere il nostro pinguino in grado di prendere la penna e scriversi finalmente il proprio diario!
Due dei filesystem che presenteremo, ReiserFS e Ext3, sono stati sviluppati in progetti nati e cresciuti nell'ambito della comunità opensource, spesso comunque supportata e finanziata da ditte private; gli altri due, JFS e XFS, sono il risultato della conversione per Linux (e rilascio sotto GPL) di due filesystem proprietari, rispettivamente di IBM e Silicon Graphics, operata dalle ditte stesse nell'ambito dei loro programmi di sviluppo di software libero. Questa tendenza è davvero lodevole, e manifesta come molte grosse società non siano più solo "interessate" a Linux, ma lo supportino attivamente, facendo proprio il modello di sviluppo "a bazaar" delineato da Eric Raymond nel bellissimo scritto "La cattedrale e il bazaar". Ma cominciamo con la panoramica:
ReiserFS è stato in origine sviluppato da Hans Reiser (ne trovate un Curriculum Vitae su http://idiom.com/~beverly/hans_resume.html, da lui viene il nome, ma l'autore respinge ogni accusa di immodestia ;o), ed è rapidamente cresciuto con l'apporto di molti altri sviluppatori. Già dal kernel 2.4.1 il suo codice è stato giudicato sufficientemente stabile (anche per i severissimi criteri dettati da Linus Torvalds riguardo al software da includere nel kernel), e perciò inserito direttamente nell'albero ufficiale dei sorgenti del "nocciolo" di Linux. È quindi stato il primo filesystem journaled per Linux a raggiungere ufficialmente una certa "stabilità". Anche dopo questo fatto importantissimo, però, ReiserFS continua a distinguersi per la grande cura che i programmatori e i manutentori dedicano alla sua distribuzione: sul suo sito (http://www.reiserfs.org/) sono presenti moltissimi patch, script e immagini di dischi, utili per adattare il filesystem ad una grande varietà di sistemi e configurazioni.
Un piccolo inciso: per questo filesystem come per gli altri vale una semplice considerazione, "recente è meglio"! Si tratta di prodotti ancora giovani, per così dire, quindi sebbene siano senz'altro utilizzabili e affidabili soffrono ancora di problemi di compatibilità, se usati in particolari configurazioni. Questi problemi del resto vengono continuamente risolti, grazie all'efficienza del modello di sviluppo aperto di cui i progetti si avvantaggiano; sarebbe quindi sempre opportuno munirsi delle ultime versioni stabili, come pure dell'ultima versione stabile del kernel, in modo da assicurarsi che siano presenti il minor numero possibile di problemi irrisolti. Ad esempio, nonostante sia presente dal kernel 2.4.1, ReiserFS è pienamente utilizzabile con NFS solo dal 2.4.7, a causa di alcuni buchi di quest'ultimo che sono stati risolti in quella release; inoltre, la versione contenuta nel kernel 2.4.9 ha seri problemi di allocazione di memoria.
Tecnicamente, ReiserFS usa un sistema ad alberi bilanciati molto sofisticato (in particolare, usa alberi B* al posto degli alberi B+ di altri FS), che permetterebbe performance molto migliori rispetto all'approccio convenzionale a blocchi usato ad esempio da Ext2; inoltre, permette una strategia di immagazzinamento dei piccoli file molto migliore. In un filesystem convenzionale, infatti, ogni file occupa uno o più blocchi; in ogni caso, l'ultimo blocco del gruppo occupato è riempito, in media, per metà. Questo comporta uno spreco di spazio che può diventare abbastanza elevato; i filesystem ad alberi bilanciati permettono di immagazzinare molti file piccoli nello stesso blocco, risparmiando spazio. Da notare che questa è la struttura normalmente utilizzata nei database relazionali; per questo motivo, si dice che ReiserFS si comporta come un database di file, con i nomi come chiavi! Rimane solo da aggiungere che, come Ext2, ha una struttura modulare a plug-in che rende molto semplice l'inserimento di nuove caratteristiche.
ReiserFS permette di creare partizioni e file grandi fino a 17 Terabyte (più di 17000 Gigabyte); ovviamente questo è un limite teorico, perché il kernel impone vincoli che costringono (si fa per dire) a minori dimensioni. In ogni caso, se in futuro il kernel abbatterà questi vincoli, non occorreranno grandi cambiamenti al filesystem. Questo concetto di scalabilità è molto importante, per un approccio lungimirante allo sviluppo della tecnologia (esperienze passate insegnano... pensate ai limiti dei vecchi BIOS!). ReiserFS è disponibile per architettura i386 e DEC Alpha.
Colpisce in particolare una nota nelle pagine del sito: se si è interessati a vedere nuove caratteristiche introdotte in ReiserFS, si è invitati a sponsorizzarne lo sviluppo; gli autori assicurano che in breve tempo le richieste verranno implementate. In effetti, già molte società sponsorizzano ReiserFS: mp3.com in passato, SuSE, ApplianceWare e BigStorage; addirittura D.A.R.P.A. (Defense Advanced Research Projects Agency, un ente governativo militare americano) sta finanziando lo sviluppo di ReiserFS 4, che porterà notevoli miglioramenti strutturali e la cui uscita è prevista per la fine di Settembre 2002.
ReiserFS, come gli altri filesystem, può essere tranquillamente usato per la partizione di root di un'installazione Linux, e da un certo tempo molte distribuzioni danno questa possibilità. Prima è stata la SuSE, dalla versione 6.4 (del resto è una distribuzione tedesca, come l'autore); le ha fatto seguito la Mandrake, dalla 7.1. Sul sito è comunque reperibile una serie di immagini per Debian e RedHat, e in un prossimo paragrafo vedremo come sia semplice effettuare la migrazione "a mano". Molti grossi nomi del panorama Linux come SourceForge e LivingXML utilizzano ReiserFS sui loro server da lungo tempo con pieno successo, a testimonianza dell'affidabilità e stabilità di questo FS.
Qui lo dico e qui lo nego; infatti ReiserFS non è per nulla esente da pecche, o per meglio dire, risente ancora di alcuni problemini di gioventù: i principali, come accennato prima, riguardano il suo utilizzo come substrato per NFS, nel quale continua a dimostrarsi instabile. Ben noti sono anche i problemi che ha avuto in passato nell'umount delle partizioni: sebbene in gran parte siano risolti, pare che non siano ancora del tutto scomparsi; per la massima stabilità, si consiglia generalmente di montare le partizioni con l'opzione notail. Questi sono comunque difetti che verosimilmente saranno corretti nelle prossime versioni di ReiserFS; in effetti, ora che il suo codice si trova nel kernel, esso ha subito un grosso incremento in termini di visibilità e base di utenza, e ciò non può che giovare ad una rapida risoluzione dei problemi.
Già il nome dà un indizio più che chiaro sulla natura di questo FS: infatti Ext3 non è null'altro che l'evoluzione di Ext2, con l'aggiunta del supporto per il journaling. In altre parole, dal punto di vista della struttura Ext3 è del tutto simile ad Ext2, con questa importantissima aggiunta. Effettivamente, Ext2 è sempre stato reputato un ottimo filesystem, con l'unico neo dato da una certa debolezza nei confronti delle interruzioni di sistema; il journaling, quindi, viene a medicare questa ferita, e rende Ext3 un filesystem davvero completo... al prezzo inevitabile di un certo degrado nelle prestazioni. Infatti, nonostante gli autori assicurino che sono state apportate delle migliorie rispetto ad Ext2 per quanto riguarda la velocità, gli accessi dovuti all'aggiornamento del journal rendono Ext3 piuttosto lento rispetto al suo antenato.
La "discendenza" di Ext3 da Ext2 ha però un'altra importantissima conseguenza: è infatti possibile convertire direttamente e in maniera molto semplice le partizioni del secondo tipo (la grande maggioranza di quelle di Linux, in effetti) nel nuovo filesystem; è sufficiente utilizzare una versione aggiornata (successiva a 1.20) dei tool di amministrazione di Ext2, gli e2fsprogs. In una sezione successiva descriveremo il procedimento nel dettaglio. È addirittura possibile montare una partizione Ext3 sotto Ext2 (e viceversa), a patto che sia stata smontata correttamente (se così non fosse, ci potrebbero essere seri problemi e perdite di dati), e vederla ad esempio da un disco di rescue che non supporta Ext3. Oppure utilizzare tutti i programmi per altri sistemi operativi che accedono a partizioni Ext2 per vedere il contenuto di partizioni Ext3. Questo rende Ext3 un filesystem davvero superaccessoriato, e la scelta ideale per coloro che progettano una migrazione, ma non vogliono dover affrontare grossi problemi (è comunque sempre opportuno effettuare dei backup! ;), o per coloro che utilizzano MSWindows assieme a Linux e non vogliono perdere la possibilità di gestire le loro partizioni Ext2 con programmi quali ad esempio Explore2fs (http://uranus.it.swin.edu.au/~jn/linux/), Norton Ghost, Powerquest PartitionMagic o DriveImage.
Ext3 è stato incluso nell'albero stabile del kernel molto di recente, a partire dalla versione 2.4.15 (ATTENZIONE! Questa versione conteneva un baco che provocava la corruzione dei filesystem del sistema-- la prima versione sicura che comprenda Ext3 è quindi la 2.4.16). Questo testimonia la stabilità raggiunta da questo FS; del resto, già da qualche anno un grosso nome nell'ambiente Linux come RPMFind lo utilizza per parte dei suoi server, con pieno successo. In tempi recenti, Ext3 è sviluppato direttamente sotto l'egida di RedHat, che ospita l'unico abbozzo di home page (su http://beta.redhat.com/index.cgi?action=ext3) che il progetto abbia. Sempre RedHat assicura di aver condotto test approfonditi che garantirebbero la stabilità di Ext3; in effetti, nei diversi benchmark che sono stati fatti Ext3 risulta il più stabile tra i quattro filesystem qui esaminati. La prudenza è però d'obbligo per un prodotto uscito alla completa "luce del sole" solo così di recente, e che quindi non ha ancora dovuto affrontare il test fondamentale, quello dell'uso comune da parte di milioni di utenti.
Il supporto per partizioni root Ext3 è incluso anche nelle recenti Mandrake 8.1, SuSE 7.3 e RedHat 7.2; questo FS diventa così la prima alternativa ufficiale a Ext2 per sistemi RedHat. Tecnicamente, come detto, è in tutto e per tutto simile a Ext2: un filesystem basato su blocchi che supporta nomi lunghi, link simbolici veloci, attributi dei file in stile UNIX, blocchi riservati per il superuser e partizioni fino a 4 Tb; si distingue insomma per una sola cosa che ha in meno: il rischio e le lunghe attese quando non si smonta il filesystem in maniera pulita!
I filesystem considerati finora hanno una caratteristica: che si tratti di un progetto programmato ex-novo come ReiserFS o del miglioramento di un progetto preesistente come Ext3, comunque sono entrambi progetti nati, cresciuti e arrivati a compimento all'interno della comunità Linux, e sono stati pensati per essa. Tuttavia, i filesystem di tipo journaled non sono certo un concetto nuovo, né tantomeno proprio di Linux: per i sistemi Microsoft è noto l'NTFS, ed anche molti UNIX proprietari possiedono un filesystem di questo tipo. Di recente, due colossi dell'informatica mondiale come Silicon Graphics (SGI) e IBM sono scesi in campo in maniera molto decisa nell'opensource, e una delle prime azioni che hanno intrapreso è stato il porting dei loro filesystem proprietari, XFS e JFS, per Linux. Si tratta quindi di filesystem pensati per sistemi diversi, ma che sono stati riadattati (e in parte riscritti) per Linux, e soprattutto sono stati rilasciati sotto GPL. Questo testimonia da un lato la netta presa di posizione di queste due aziende, e dall'altro come effettivamente si possa parlare di OpenSource propriamente detto.
Il primo Maggio 2001 è stata rilasciata la versione 1.0 di XFS, il filesystem journaled di SGI, sviluppato originariamente (fin dal 1994) per IRIX e hardware Silicon Graphics. Ufficialmente è stato reso disponibile solo per architetture x86, ma è stato fatto girare anche sotto sistemi DEC Alpha, IA64 e Sparc64. Per ora, tale filesystem non è disponibile direttamente nel kernel, ma si può scaricare dalla home page del progetto, su http://oss.sgi.com/projects/xfs/index.html, sotto forma di patch. Questo metodo di distribuzione è piuttosto scomodo, per la verità, visto che lega l'utente a una particolare versione del kernel, e convive male con altri programmi che sfruttano patch per installarsi (come vedremo, JFS stesso lo fa). In particolare, l'attuale release 1.0.2 è rilasciata come patch al kernel 2.4.14, e impone l'uso di questa versione. Ovviamente l'aggiornamento è legato a nuove release del filesystem, quindi il problema è relativo: non appena queste saranno disponibili, saranno applicate alla versione corrente del kernel. C'è anche da dire che l'ultimissima versione del software, creata sull'ultima versione disponibile del kernel, è prelevabile da CVS; questo però è da considerarsi software non stabile, quindi secondo il buon senso ne è sconsigliato l'uso.
Tecnicamente, XFS è un filesystem journaled interamente progettato a 64 bit; di per sé può teoricamente gestire partizioni grandi fino a un Esabyte (un miliardo di Gigabyte!), ma applicato ai sistemi odierni soffre di alcune "limitazioni": la dimensione dei blocchi è limitata a 4 Kb su architettura IA32, e questo rende la dimensione massima dei file è 16 Terabyte, e quella di un filesystem "solo" 2 Terabyte. Questi numeri sembrano enormi, ma pensando in prospettiva è verosimile che in un futuro non troppo lontano possano essere considerati normali. È allora molto positivo che già da ora siano tecnicamente supportati.
NFS e Samba, nonché RAID e filesystem loopback sono pienamente supportati; la corrente versione 2 del protocollo di NFS è limitata a filesystem a 32 bit, quindi applicata a XFS ne indirizzerà solo questo numero; la versione 3, invece, supporterà tutti i 64 bit. Una caratteristica importante di XFS è la presenza degli strumenti per il backup ed il restore del filesystem, che per di più utilizzano un formato comune a Linux e IRIX: i backup fatti sotto un sistema saranno quindi pienamente portabili sull'altro, con evidenti vantaggi di flessibilità e migrazione. XFS supporta le quote, sia per utente che per gruppo; tuttavia, SGI avverte che tale supporto funziona senza problemi solo dalla versione 1.0.1 in poi. XFS inoltre supporta il Posix Access Control List (meglio noto come ACL), un sistema avanzato di controllo dei permessi di accesso alle directory.
SGI riporta di aver condotto test esaustivi di stabilità su una grande varietà di macchine e configurazioni. Come sempre queste informazioni, soprattutto se date in maniera così generica, sono da prendere con le pinze; ma in effetti XFS appare un prodotto già abbastanza stabile. SGI stessa segnala nelle FAQ (http://oss.sgi.com/projects/xfs/faq.html) un'incompatibilità con le schede SCSI AIC7xxx, comunque risolta a partire dalla versione 2.4.5 dei driver di queste ultime. Per il resto, c'è da dire che il filesystem si dimostra abbastanza lento nella cancellazione di file, e che Mandrake riporta un problema: XFS non può condividere il bootloader con altri Linux installati nella stessa macchina, perciò se usate XFS per la partizione in cui risiede la cartella /boot probabilmente non riuscirete a fare il dual-boot con altri Linux. Mandrake 8.1 include il supporto per creare la partizione di root anche sotto XFS.
Il 28 Giugno 2001 viene rilasciata da IBM la versione 1.0.0 di JFS, il suo filesystem proprietario (cioè, ex tale! ;) utilizzato da tempo su AIX e nei suoi server enterprise. Si tratta di un filesystem journaled, che utilizza strategie proprie dei database per fornire una ottimale allocazione dello spazio e un'ampia banda, ideale quindi per server e altre applicazioni professionali... nulla di nuovo sotto il sole, insomma, ed in effetti nelle promesse i 4 filesystem esaminati non è che differiscano poi di tanto. Peculiare è però come IBM presenta le sue motivazioni: piuttosto di vantare una superiorità del suo FS rispetto agli altri, dichiara nell'home page (http://oss.software.ibm.com/jfs di averlo rilasciato "nella speranza che sia almeno in parte utile a portare le migliori tecniche di journaling sotto Linux"; nelle FAQ (http://www.moshebar.com/modules.php?op=modload&name=FAQ&file=index&myfaq=yes&id_cat=1&categories=JFS), a proposito di un confronto con ReiserFS, gli sviluppatori dichiarano: "[...]avere più di un filesystem journaled in sviluppo per Linux è un bene. La comunità di sviluppatori sta lavorando in comune accordo per avere un migliore substrato per i filesystem, in Linux. Inoltre, poiché entrambi [ReiserFS e JFS] sono rilasciati sotto GPL, potremo in futuro condividere gli algoritmi, e rendere entrambi i filesystem migliori". Questo atteggiamento di collaborazione con gli altri progetti è molto promettente, e dimostra davvero come e fino a che livello "Big Blue" creda nell'opensource.
Effettivamente, IBM sfrutta molto la collaborazione della comunità per il suo progetto; lo dimostra ad esempio l'adozione di bugzilla, che ormai è il metodo standard di reporting dei bug, o la migrazione del progetto su SourceForge (http://sf.net/). I risultati si vedono: dall'uscita della versione 1.0.0 sono già state pubblicate 12 release, contro ad esempio le 2 di XFS; il ritmo è di più di una al mese, il che assicura una buona integrazione anche con i kernel più recenti. Anche JFS come XFS non è inserito nell'albero dei sorgenti del kernel, e va scaricato come patch. IBM ha però strutturato diversamente la cosa; nel pacchetto da scaricare ci sono effettivamente più patch: una è comune a tutti i kernel, le altre sono specifiche ognuna di una o più versioni: in base alla versione del kernel che usa, l'utente potrà quindi adattare JFS alla sua specifica esigenza. Questo è un ottimo metodo, e permette una flessibilità decisamente maggiore rispetto ad altri software basati su patch al kernel. Attualmente sono disponibili patch per i kernel della serie 2.4.x e, a partire dalla 1.0.11, per quelli della serie 2.5.x; la 1.0.10 è stata l'ultima versione rilasciata anche per la serie 2.2.x.
Ma non è tutt'oro quel che luccica! In effetti, nelle varie prove che sono state effettuate, JFS è risultato il filesystem meno stabile tra i quattro presi in esame. Mandrake, che lo supporta nella sua 8.1 (come del resto SuSE nella 7.3) completando così il lotto di filesystem journaled, riporta che sarebbe inutilizzabile per la partizione di root, corrompendo i dati (!) dopo appena una trentina di boot; come XFS, non è utilizzabile per la partizione contenente /boot, se si vogliono installare altri Linux; inoltre, inchioderebbe il sistema con grande facilità. C'è però da dire che ci si riferisce alla versione 1.0.4; la versione attuale, ben sette release dopo, potrebbe rivelarsi decisamente più stabile.
Una peculiarità di JFS è il "ritorno" di defrag, strumento tipico di ben altri filesystem: nonostante, al pari di Ext2/3, ReiserFS e XFS, JFS adotti strategie avanzate per limitare la frammentazione dei file, pare che queste non siano sufficienti; IBM ha così realizzato un utile strumento di deframmentazione, che però in ambiente Linux suona decisamente "strano"! La dimensione massima di un file in JFS è 512 Terabyte con blocchi di 512 b, e 4 Petabyte con blocchi di 4 Kb; quella di un filesystem è 4 Petabyte con blocchi di 512 b e 32 Petabyte con blocchi di 4 Kb; questi limiti sono comunque, come sempre, teorici.
A questo punto una domanda sorge spontanea: quale scegliere? La comparazione tra i quattro non è così immediata: tutti promettono fondamentalmente un'unica (e molto importante) cosa, sicurezza per i dati ed eliminazione dei tempi di attesa, e tutti la mantengono. Una prima distinzione si può fare sulla base d'utenza: ReiserFS e Ext3, essendo stati inclusi nel kernel, hanno un bacino di utilizzatori potenzialmente molto maggiore, soprattutto ReiserFS ha dimostrato affidabilità per lungo tempo, come detto, anche utilizzato in progetti piuttosto rilevanti. Questo dà buone garanzie non solo sulla stabilità, ma pure sulla velocità di correzione dei bug che si venissero a scoprire. Ext3 ha inoltre dalla sua l'estrema facilità di migrazione da Ext2, e il grande supporto che ne eredita; questo può fare senza dubbio volgere lo sguardo verso di esso a tutti coloro che non hanno voglia di affrontare i disagi di una migrazione più tortuosa (fate sempre comunque un backup dei dati rilevanti! :o). XFS e JFS hanno dietro le spalle due nomi decisamente grossi, e una lunga storia sotto altri sistemi; questo non assicura necessariamente la qualità del porting, ma mette di certo al riparo da errori di progettazione. Altro discorso va fatto per la comodità d'uso: il fatto che ReiserFS e Ext3 siano inclusi nel kernel li rende ideali; gli altri due vincolano per forza di cose a particolari versioni dello stesso, e l'utilizzo limita potenzialmente l'applicazione di altre patch. Nota: se volete provare JFS e XFS assieme, presso http://ftp.uni-duisburg.de/Linux/filesys/ potete trovare alcune patch che lo rendono possibile.
Le considerazioni non finiscono qui. Nessuno di questi FS, nelle loro versioni stabili, ha resistito alla prova più importante, quella del tempo: teoricamente se avviati per lunghi periodi in condizioni di stress massimo, potrebbero magari tra parecchi mesi rivelare grossi buchi, e condurre a serie perdite di dati. Comunque, questo discorso vale per molti altri componenti di Linux, compreso il kernel stesso: aggiornare spesso i propri software, man mano che i buchi son scoperti e riparati, potrebbe essere una buona misura precauzionale. ReiserFS è sconsigliabile per l'uso con NFS; XFS è sconsigliabile se si creano e cancellano grossi quantitativi di file; JFS è sconsigliabile per la partizione di root... tutti questi problemi potranno essere risolti in un immediato futuro, se non lo sono già; come sempre, il primo discriminante è il buon senso.
A livello di prestazioni, il discorso si fa delicato: ogni produttore cita dei benchmark, che puntualmente vedono primeggiare il proprio prodotto; il discorso è che è facilissimo far pendere l'ago della bilancia da una o dall'altra parte, sfruttando i punti di forza di un filesystem rispetto ad un altro; non è questione di truccare i dati, anzi, la buona fede è fuori discussione! Semplicemente, test diversi conducono a risultati molto diversi. Inoltre, il rapido aggiornamento di tutti questi FS rende un benchmark obsoleto ...non appena viene pubblicato! Comunque, facendo base sui siti ufficiali dei filesystem qui citati, e lavorando un po' con un motore di ricerca, dovreste essere in grado di reperirne un bel po'. Tutti concordano, comunque, sul fatto che Ext2 è un 10-20% più veloce. La sensazione generale è che tutti i filesystem siano adeguati per qualsiasi uso, e la discriminazione dovrebbe essere effettuata su altre basi.
In definitiva: ReiserFS dà più garanzie di affidabilità, visto che è stato usato da molto tempo, ed è presente nel kernel da parecchio; questo, se non si usa NFS (e, ma è solo un consiglio, se si ha cura di montare le partizioni con notail). Altrimenti, è da provare. Ext3 è adatto a coloro che vogliono migrare con facilità e senza troppi problemi (ancora, fate un BACKUP!), e hanno un parco software per Ext2 che dispiacerebbe lasciare. XFS è un buon FS all-purposes, stabile (a quanto si può vedere) e debole solo nella cancellazione dei file; questo se non dà fastidio il fatto che viene aggiornato un po' poco spesso, e vincola a versioni particolari del kernel (o se si trovano patch realizzate da terzi). JFS va provato; potrebbe aver risolto i suoi problemi di gioventù, come no. Di certo è un prodotto molto interessante, e IBM è comunque una garanzia.
Bene, speriamo di aver fornito una panoramica quanto più completa su questi aspetti relativamente nuovi del nostro amato pinguino; di certo, l'introduzione di questi filesystem è una novità molto importante, sia per l'utenza casalinga che per le grandi industrie, che possono ora trovare degli strumenti potenti e flessibili (e che condividono tutti i vantaggi del modello aperto di Linux) per migliorare la sicurezza dei propri dati. Nelle successive sezioni vedremo nella pratica come effettuare l'installazione di questi FS, e come migrare le partizioni da Ext2 a un nuovo FS.
Vediamo ora come installare le varie parti che ci renderanno capaci di utilizzare uno di questi filesystem. I passi da fare sono fondamentalmente due: attivare il supporto nel kernel, se non lo avete già, e compilare ed installare i programmi di utilità, se non sono forniti con la vostra distribuzione. Alcune distribuzioni recenti, come appunto Mandrake, SuSE e RedHat, hanno il supporto per uno o più di questi filesystem già incluso; non sarà necessario allora fare nulla di più.
Partiamo dal kernel. Il nostro intento sarà di attivare il supporto ai filesystem, cosicché il sistema operativo sappia come riconoscerli e come accedere ai dati immagazzinati al loro interno. Per questi passaggi è richiesta una minima familiarità con le procedure di configurazione e compilazione, ma non c'è nulla di difficile. Se si ha un kernel recente è possibile che ReiserFS e Ext3 siano già installati; non occorrerà allora applicare nessuna patch, mentre per JFS e XFS comunque sì. Queste patch sono generate contro i kernel "ufficiali", quelli cioè scaricati da http://www.kernel.org; se la vostra distribuzione installa un kernel modificato, probabilmente la patch non funzionerà. In tal caso, se per qualsiasi motivo non potete adottare un kernel ufficiale, la cosa migliore da fare è indagare nel sito della vostra distribuzione se sia previsto un aggiornamento del kernel "proprietario".
Qui potete scaricare le patch:
Una volta che avrete ciò che fa al caso vostro,
portatevi nella directory dei sorgenti del kernel ed applicate la patch; ad
esempio, se è in formato BZip2, potreste eseguire:
cd /usr/src/linux/
bunzip2 -c patch-qualcosa.bz2 | patch -p1
|
Fatto questo, non rimane che salvare, ricompilare e
reinstallare il kernel nel modo consueto, ad esempio dando
make dep clean bzImage modules modules_install bzlilo
|
modprobe nomefs
|
Da solo, il supporto al filesystem purtroppo non basta. Il sistema ora sa come riconoscerlo e trattarlo, ma non ha ancora i "ferri del mestiere", i programmi che servono per gestirlo. Chi è pratico di Ext2 probabilmente conosce gli e2fsprogs, come mke2fs, tune2fs, e2fsck o e2label; bene, ogni filesystem ha i propri. Generalmente si trovano sotto forma di pacchetti tar.gz; di norma sono disponibili anche i pacchetti DEB e RPM, basta cercare nel sito. L'installazione dei pacchetti non si discosta per nulla dall'usuale; la procedura, insomma, è la stessa che si seguirebbe per altri applicativi (./configure - make - make install o poco più); in ogni caso, una lettura del file INSTALL contenuto nel pacchetto darà tutte le informazioni necessarie.
ReiserFS fornisce i seguenti programmi, che possono essere scaricati nelle reiserfs utils (http://www.reiserfs.org/download.html); sono tutti correlati di pagina man:
Ora che abbiamo tutto quanto installato e configurato, passiamo a un altro problema. Probabilmente ora vorrete utilizzare qualcuno di questi filesystem, per mettervi i vostri dati, per farvi qualche benchmark, o anche solo fare i cafoni con gli amici! ;) Vorrete quindi convertire una o più delle partizioni che ora avete in Ext2 nel nuovo filesystem. Questa appendice spiega come.
L'avevamo ben detto prima: Ext3 fa della
facilità di migrazione uno dei suoi punti di forza. Infatti, trasformare una
partizione Ext2 in una Ext3 è semplice e veloce, e si fa utilizzando il comando
tune2fs. Una volta che avrete fatto un backup dei dati ('n si sa
mai...), basterà invocarlo col parametro -j:
tune2fs -j /dev/xdxX
|
Se si vuole invece creare una partizione Ext3,
basterà richiamare il programma mke2fs, sempre con lo switch
-j:
mke2fs -j /dev/xdxX
|
I comandi citati accettano un altro switch, -J, che viene usato per specificare diversi parametri del journal; poiché è difficile che torni utile ed è potenzialmente pericoloso, rimandiamo chi volesse approfondire l'argomento alle pagine man.
Veniamo ora agli altri tre filesystem. Per questi,
non è possibile convertire direttamente il filesystem esistente; non rimane
perciò che copiare i dati in un'altra partizione (eventualmente usando tar e gz
o bz2 per comprimerli), smontare la partizione originaria, formattare col nuovo
filesystem (utilizzando mkfs -t nomeFS), rimontare la
partizione avendo cura di specificare il nuovo filesystem se necessario,
ritrasferire i dati e cambiare eventualmente il riferimento in
/etc/fstab. Un po' laborioso e lungo, ma semplice! Supponiamo che
si voglia cambiare la partizione /dev/hdb1 da Ext2 a XFS, e che si
abbia a disposizione una /dev/hdb2 con un certo spazio libero;
monteremo entrambe in directory fittizie /mnt/tmp1 e
/mnt/tmp2:
# monto le due directory
mount /dev/hdb1 /mnt/tmp1
mount /dev/hdb2 /mnt/tmp2
# copio i dati bzippandoli
tar --bzip2 -cf /mnt/tmp2/archivio.tar.bz2 /mnt/tmp1/*
# smonto la partizione, la formatto e la rimonto
umount /dev/hdb1
mkfs -t xfs /dev/hdb1
(...rispondere alle domande...)
mount -t xfs /dev/hdb1 /mnt/tmp1
# ritrasferisco i dati
cd /mnt/tmp1
tar --bzip2 -xf /mnt/tmp2/archivio.tar.bz2
|
Il problema sorge a voler cambiare il filesystem della directory di root; essa infatti non può essere smontata a sistema attivo! Il procedimento si complica, e non di poco. Lo descriveremo senza approfondire quegli argomenti che esulano dagli scopi di questo articolo; del resto, chi lo volesse applicare dovrebbe avere una conoscenza approfondita del funzionamento del sistema. Queste indicazioni hanno comunque carattere generale, vanno adattate ad ogni sistema; ci si assicuri di fare tutto nel modo corretto, di fare un bel backup dei dati, e si proceda, insomma, con i piedi di piombo!
linux root=/dev/xdxX init=/bin/bash
|
L'autoreGermano "Mano" Rizzo (mano@pluto.linux.it), studente in Ingegneria Elettronica, è programmatore Java e PHP presso una ditta di software web. Si interessa di Linux da parecchi anni, spaziando in svariati campi, in particolare la programmazione C e gli aspetti legati al kernel. |
|
|
<- SL: Postfix - Copertina - SL: Protocolli -> |
|