Attachment 71421 Details for Bug 110455 – italian translation of /doc/en/articles/afig-ct-ext3-intro.xml

italian translation of /doc/en/articles/afig-ct-ext3-intro.xml

afig-ct-ext3-intro.xml (text/plain), 19.19 KB, created by Andrea Menegolo on 2005-10-25 09:51:26 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Andrea Menegolo

Created: 2005-10-25 09:51:26 UTC

Size: 19.19 KB

patch

obsolete

><?xml version='1.0' encoding='UTF-8'?>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>
><guide link="/doc/it/articles/afig-ct-ext3-intro.xml" disclaimer="articles"
>lang="it">
>
><title>Guida alle implementazioni di filesystem avanzati: introduzione ad
>ext3</title>
>
><author title="Autore">
>  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
></author>
>
><author title="Traduttore">
>  <mail link="menegolo_andrea@yahoo.it">Andrea Menegolo</mail> 
></author>
>
>
>
>
>
><abstract>
>Con la versione 2.4 del kernel Linux furono introdotti un bel po' di nuovi
>filesystem tra i quali ReiserFS, XFS, GFS e altri. Questi filesystem sembrano
>interessanti, ma che potenzialitÃ  hanno esattamente, in che ambiti sono
>consigliabili, e cosa si puÃ² dire per quanto riguarda il loro uso in modo sicuro
>in un ambiente Linux di produzione? Daniel Robbins risponde a queste domande
>mostrando come usare questi nuovi filesystem di tipo avanzato sotto Linux 2.4.
>In questa puntata, Daniel dÃ  uno sguardo a ext3, una nuova versione, migliorata,
>di ext2, che implementa il journaling.
></abstract>
>
><version>1.1</version>
><date>2005-10-09</date>
>
><chapter>
><title>Introduzione</title>
><section>
><body>
>
><p>
>Nelle puntate precedenti abbiamo esaminato filesystem non tradizionali come
>tmpfs e devfs. Ora Ã¨ tempo di tornare ai filesystem studiati per essere
>utilizzati su hard-disk e cominceremo occupandoci di ext3. Il filesystem ext3,
>progettato dal Dr. Stephen Tweedie, Ã¨ stato costruito a partire dalla struttura
>di un filesystem giÃ  esistente: ext2; infatti ext3 Ã¨ molto simile ad ext2 ad
>eccezioni di una piccola (ma importante) differenza: ext3 supporta il
>journaling. Proprio per questa piccola implementazione penso che troverete che
>ext3 ha molte sorprendenti ed intriganti possibilitÃ . In questo articolo farÃ² in
>modo di darvi una buona conoscenza delle possibilitÃ  di ext3 confrontato con gli altri
>filesystem journaling che sono attualmente disponibili. Nel prossimo articolo
>vedremo come impostare la propria macchina per far funzionare ext3.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Conoscere e capire Ext3</title>
><section>
><body>
>
><p>
>Allora, com'Ã¨ ext3 se confrontato con ReiserFS? Nel precedente articolo
>ho spiegato che ReiserFS Ã¨ molto indicato per gestire file di piccole dimensioni
>(al di sotto dei 4K), ed in certe situazioni la gestione dei piccoli file
>risulta essere da dieci a quindici volte piÃ¹ performante con ReiserFS rispetto a
>ext2 ed ext3. Ma come ReiserFS presenta molti punti di forza, esso Ã¨ meno
>performante sotto altri punti di vista. Nell'ultima implementazione di ReiserFS
>(la versione 3.6), alcuni schemi di accesso ai file possono determinare
>dei veri e propri crolli di prestazioni rispetto a ext2 ed ext3, in particolare
>la lettura di directory di grandi dimensioni di posta elettronica. Inoltre
>ReiserFS non ha una buona registrazione di traccia di NFS e le prestazioni in
>presenza di file frammentati sono ridotte. Dall'altro lato ext3 Ã¨ un filesystem
>ben costruito. Ã molto simile ad ext2; non raggiungerÃ  mai le performance
>ultraveloci di ReiserFS con i piccoli file, ma nemmeno soffrirÃ  di imprevedibili
>anomalie di funzionamento o grande variabilitÃ  nelle prestazioni.
></p>
>
><p>
>Una delle belle cose di ext3 Ã¨ che, essendo basato sul codice di ext2,
>l'organizzazione dei dati di ext2 e di ext3 sul disco Ã¨ identica; questo
>significa che se si smonta un filesystem ext3 in modo pulito, questo puÃ² venir
>rimontato come un filesystem ext2 senza alcun problema. E non Ã¨ tutto. Grazie al
>fatto che ext2 ed ext3 usano metadata identici, Ã¨ possibile eseguire l'upgrade
>di un filesystem ext2 ad ext3. Certo, hai letto bene. Aggiornando qualche
>utility del sistema, installando un kernel 2.4 e digitando un comando tune2fs per
>ogni filesystem da aggiornare, puoi convertire il tuo server ext2 in una
>macchina che sfrutta i vantaggi del journaling di ext3. Puoi farlo addirittura
>mantenendo montati i filesystem ext2. La conversione dall'uno all'altro Ã¨
>sicura, revesibile e facilissima, inoltre, al contrario di quanto succederebbe
>per passare a XFS, JFS o ReiserFS, non c'Ã¨ bisogno di fare il backup dei dati e
>ricreare i filesystem da zero. Ora, per un istante, pensa alle migliaia di
>server di produzione che utilizzano ext2 e a cui basterebbero un paio di minuti
>per effettuare un upgrade ad ext3; ora hai un'idea dell'importanza che ricopre
>ext3 nella comunitÃ  di Linux.
></p>
>
><p>
>Se dovessi descrivere ext3 con un'unica parola, userei "comodo". Ã estremamente
>facile fare l'upgrade ad ext3 di un sistema che utilizza ext2, e dopo averlo
>fatto non ci si imbatterÃ  in alcuna sorpresa per quanto riguarda le prestazioni.
>E c'Ã¨ anche un altro aspetto che rende ext3 molto comodo: questo filesystem Ã¨
>uno dei piÃ¹ affidabili filesystem journaled disponibili per Linux, come mi
>accingo a spiegarvi.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Ext3 Ã¨ affidabile</title>
>
><section>
><body>
>
><p>
>Oltre ad essere compatibile con etx2, ext3 eredita altri vantaggi dall'utilizzo
>della stessa struttura dei metadata di ext2. Infatti gli utilizzatori di ext3
>possono utilizzare il tool fsck che risulta essere molto stabile e affidabile.
>Un'obiezione puÃ² essere che il principale motivo per cui si usa un filesystem
>journaled Ã¨ quello di evitare di fare il chek completo del filesystem con fsck;
>perÃ² se per qualche motivo ci si dovesse imbattere in metadata corrotti, a causa
>di un'anomalia del kernel o per un hard disk malfunzionante o per qualsiasi
>altra cosa, di sicuro apprezzerai che ext3 puÃ² utilizzare il tool fsck di ext2.
>Al contrario il tool fsck di ReiserFS Ã¨ appena nato e la riparazione di metadata
>corrotti, nel momento del bisogno, puÃ² risultare un processo difficile
>e pericoloso.
></p>
>
></body>
></section>
>
><section>
><title>Il journaling metadata-only</title>
><body>
>
><p>
>Ã interessante vedere come il modo di gestire il journaling di ext3 Ã¨ molto
>diverso da quello di ReiserFS e di altri filesystem journaled. Con ReiserFS, XFS
>e JFS il driver del filesystem registra i metadata, ma non si preoccupa di
>prendere delle misure di sicurezza per quanto riguarda la registrazione dei dati
>veri e propri sul disco. Con questo tipo di journaling (metadata-only) il
>metadata del filesystem Ã¨ veramente molto robusto e probabilmente non avrai mai
>bisogno di eseguire un chek completo del filesystem con fsck. D'altro canto dei
>riavvii improvvisi e crash del sistema possono portare ad una corruzione
>significativa dei dati che si stavano modificando. Ext3 usa un paio di soluzioni
>innovative per raggirare questo problema. Le vedremo subito.
></p>
>
><p>
>Ma prima Ã¨ importante capire come esattamente il journaling di tipo
>metadata-only prima o poi distruggerÃ  la tua vita. Facciamo un esempio:
>supponiamo che tu stia modificando il file /tmp/miofile.txt e ad un certo punto
>la macchina vada in crash costringendoti a riavviarla brutalmente. Se stavi
>usando un filesystem con journaling di tipo metadata-only come ReiserFS, XFS e
>JFS i metadata potranno essere riparati facilmente, grazie al journal, e non ci
>sarÃ  bisogno di eseguire un estenuante chek con fsck.
></p>
>
><p>
>PerÃ² c'Ã¨ una possibilitÃ  non nulla che quando andrai ad aprire il file
>/tmp/miofile.txt con il tuo editor di testi preferito, nel file non solo
>potrebbero mancare le ultime modifiche, ma il file potrebbe contenere anche un
>po' di spazzatura oppure portebbe risultare addirittura completamente
>inaccessibile. Non voglio dire che questo accade ogni volta, ma potrebbe
>succedere e spesso accade.
></p>
>
><p>
>E ciÃ² accade per questo motivo. I filesystem journaled tipici come ReiserFS, XFS
>e JFS danno moltissima importanza ai metadata, ma non fanno sufficiente
>attenzione ai dati. Nell'esempio fatto in cui i dati risultavano effettivamente
>corrotti, il driver del filesystem stava per modificare parecchi blocchi del
>filesystem. Il driver aggiornÃ² i relativi metadata, ma non ebbe il tempo di
>trasferire i dati dalla cache in memoria ai blocchi fisici del disco. CosÃ¬
>quando si Ã¨ provato ad aprire il file /tmp/miofile.txt in un editor, una parte
>del file conteneva spazzatura (blocchi di dati che non sono stati registrati
>prima del crash).
></p>
>
></body>
></section>
>
></chapter>
>
><chapter>
><title>L'approccio di ext3</title>
><section>
><body>
>
><p>
>Ora che conosciamo meglio il problema, vediamo come ext3 implementa il
>journaling. In ext3 il codice del journaling usa un'API particolare chiamata
>Journaling Block Device layer (JBD). Il JBD Ã¨ stato pensato al fine preciso di
>poter implementare un journal su qualsiasi tipo di supporto a blocchi. Il
>journaling di ext3 Ã¨ stato costruito portando l'API di JBD al suo interno.
>Facciamo un esempio del funzionamento: il codice del filesystem di ext3 informa
>il JBD delle modifiche che sta per effettuare e chiede al JBD il permesso prima
>di modificare qualsiasi dato sul disco. In questo modo al JBD Ã¨ affidato il
>compito di gestire il journaling per conto del driver del filesystem di ext3. Ã
>proprio un bel meccanismo e, grazie al fatto che il JBD Ã¨ sviluppato
>separatamente come un'entitÃ  generica, esso potrÃ  essere usato nel futuro per
>implementare il journaling in altri filesystem.
></p>
>
><p>
>Ci sono poi un paio di cose molto curate del journal di ext3 gestito dal JBD.
>Per prima cosa il journal di ext3 Ã¨ registrato in un inode (che sostanzialmente
>Ã¨ un file). A seconda di come si attiva il filesystem ext3 nel proprio sistema
>si sarÃ  o meno in grado di vedere questo file che viene posto in /.journal. Di
>sicuro, salvando il journal in un inode, ext3 Ã¨ in grado di implementare il
>journal nel filesystem senza il bisogno di aggiungere estensioni alla struttura
>dei metadata che potrebbero quindi portare ad incompatibilitÃ  con ext2. Questo Ã¨
>il motivo fondamentale per cui ext3 mantiene la compatibilitÃ  con ext2 e di
>conseguenza con il driver del filesystem di ext2.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Modi diversi di implementare il journaling</title>
><section>
><body>
>
><p>
>Non desta meraviglia che ci siano molti modi diversi per implementare il
>journal in un filesystem. Per esempio lo sviluppatore di un filesystem puÃ²
>programmare un journal che registra la serie di byte che verranno modificati nel
>filesystem vero e proprio. Il vantaggio di questo approccio Ã¨ che il journal sarÃ 
>in grado di salvare molte piccole modifiche del filesystem in modo molto
>efficiente, poichÃ© si preoccuperÃ  di registrare solo i byte che verranno
>modificati e nessun'altra informazione superflua.
>
></p>
>
><p>
>Il JBD ha un approccio diverso e per certi versi migliore. Invece di registrare
>la serie di byte che dovranno essere modificati, JBD salva gli interi blocchi
>del filesystem che sono interessati dall'operazione sul disco. Il driver del
>filesystem di ext3 usa anch'esso questo approccio e salva la copia completa dei
>blocchi modificati (di 1K, 2K o 4K) nella memoria per tenere traccia delle
>operazioni di input/output in esecuzione. Al primo sguardo questo puÃ² sembrare
>un po' uno spreco di risorse. Dopotutto nei blocchi completi sono presenti i
>dati modificati, ma possono esserci anche dati non modificati effettivamente
>(sul disco).
></p>
>
><p>
>L'approccio usato dal JBD Ã¨ chiamato journaling fisico, che significa che JBD usa
>i blocchi fisici completi, uguali alla struttura sottostante, per implementare il
>journal. Al contrario quando il journal salva solo la serie di byte modificati,
>anzichÃ© i blocchi interi, si parla di journaling logico e questo Ã¨ il metodo
>usato da XFS. PoichÃ© ext3 utilizza il journaling fisico, un journal di ext3 avrÃ 
>bisogno di uno spazio maggiore su disco rispetto al journal, per esempio, di
>XFS. Ma il fatto che ext3 utilizzi blocchi completi sia al suo interno che
>per il journal ha fatto si che la struttura ed il codice non raggiungesse la
>complessitÃ  che sarebbe stata invece necessaria per implementare un journaling
>logico. Oltre a questo, l'uso di blocchi interi permette ad ext3 di ottenere
>qualche ulteriore ottimizzazione, come il riunire piÃ¹ operazioni di input/output
>pendenti in un singolo blocco all'interno della stessa struttura dati residente
>in memoria. Questo a sua volta permette ad ext3 di scrivere piÃ¹ cambiamenti del
>disco in una sola operazione di scrittura, anzichÃ© in molte. Inoltre, poichÃ© il
>blocco di dati considerato Ã¨ salvato in memoria, non sono necessarie o sono
>addirittura assenti le operazioni da effettuare sui dati in memoria prima della
>scrittura sul disco, riducendo considerevolmente l'utilizzo della CPU.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Ext3, il protettore dei dati</title>
><section>
><body>
>
><p>
>Vediamo infine come il filesystem ext3 gestisce efficacemente sia i metadata che
>i dati del journal, raggirando il problema della corruzione dei dati che ho
>descritto all'inizio dell'articolo. Infatti, a dire il vero, ext3 utilizza due
>modi per garantire l'integritÃ  dei dati e metadata.
></p>
>
><p>
>Originariamente ext3 fu concepito per eseguire un journaling completo di dati e
>metadata. In questo metodo (chiamato "data=journal" mode), il JBD registra tutti
>i cambiamenti fatti al filesystem, sia che si tratti dei dati che dei metadata.
>PoichÃ© sia i dati che i metadata sono registrati nel journal, JBD puÃ² usare il
>journal per riportare ad uno stato consistente sia i metadata che i dati. Il
>rovescio della medaglia dell'effettuare il journaling di tutti i dati Ã¨ che esso
>puÃ² risultare lento, anche se Ã¨ possibile ovviare in parte a questa diminuzione
>delle prestazioni impostando un journal relativamente grande.
></p>
>
><p>
>Ultimamente Ã¨ stato aggiunto ad ext3 un nuovo metodo di journaling che assicura
>i vantaggi del journaling completo, ma senza penalizzare fortemente le
>prestazioni. Con questo nuovo metodo vengo registrati solo i metadata. Tuttavia
>il driver del filesystem di ext3 tiene traccia di ogni blocco di dati
>corrispondente ad ogni aggiornamento dei metadata, ragruppandoli in un'unica
>entitÃ  chiamata transizione. Quando una transizione Ã¨ applicata al filesystem
>vero e proprio, i blocchi dei dati sono per prima cosa scritti sul disco. Una
>volta che i dati sono stati scritti sul disco i cambiamenti apportati ai
>metadata sono scritti sul journal. Usando questa tecnica (chiamata
>"data=ordered" mode) ext3 puÃ² assicurare la consistenza dei dati e metadata
>anche se vengono registrati nel journal solo i cambiamenti effettuati ai
>metadata. Ext3 usa questo metodo di default.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Conclusioni</title>
><section>
><body>
>
><p>
>Ultimamente molte persone stanno cercando di capire quale sia il miglior
>filesystem journaling di Linux. In veritÃ  non c'Ã¨ un unico filesystem giusto per
>tutte gli utilizzi; ogniuno ha i suoi punti di forza. Questo Ã¨ uno dei vantaggi
>nel fatto che ci siano cosÃ¬ tanti filesystem di nuova generazione in Linux tra i
>quali scegliere. Quindi, anzichÃ© prendere a caso un filesystem considerandolo il
>migliore ed usarlo per tutti gli impieghi concepibili, sarebbe meglio conoscere
>e capire i punti di forza e di debolezza di ogni filesystem in modo da poter
>prendere una decisione ponderata su quale usare.
></p>
>
><p>
>Ext3 ha molti punti di forza. Ã stato costruito per essere estremamente facile
>da usare. Ã basato sul codice molto stabile di ext2 ed eredita da esso un
>fantastico strumento di chek del filesystem (fsck). E le proprietÃ  del
>journaling di ext3 sono state pensate in particolare per assicurare l'integritÃ 
>sia dei dati che dei metadata. Dopotutto ext3 risulta essere veramente un bel
>filesystem, ed un degno successore dell'ormai venerabile ext2. Ti invito a
>prendere visione del mio prossimo articolo, dove spiegherÃ² come impostare e
>preparare la tua macchina all'utilizzo di ext3. Intanto potresti voler dare
>un'occhiata alle risorse presenti nei link che seguono.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Risorse</title>
><section>
><body>
>
>
>
><p>
>Puoi leggere <uri
>link="http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html">un
>libretto</uri> del Dr. Stephen Tweedie che tratta di ext3 e fa una presentazione
>dei filesystem journaling. Fu presentato all'Ottawa Linux Symposium nel Luglio
>del 2000.
></p>
>
>
><p>
>Per sapere qualcosa di piÃ¹ sull'uso di ext3 con un kernel 2.4 vedi la pagina
><uri link="http://www.zip.com.au/~akpm/linux/ext3/index.html">ext3 per 2.4</uri>
>di Andrew Morton. Andrew Morton Ã¨ il responsabile del porting di ext3 sul kernel
>2.4 ed ha contribuito in modo insostituibile alla scrittura di questo articolo.
>Se non riesci ad attendere l'uscita del mio prossimo articolo, Andrew ha scritto
>una bellissima pagina su <uri
>link="http://www.zip.com.au/~akpm/linux/ext3/ext3-usage.html">ext3 ed il suo uso
>con il kernel 2.4</uri> che ti mostrerÃ  come configurare ed utilizzare ext3
>sulla tua macchina in poco tempo.
></p>
>
><p>
>Per tenerti aggiornato sui nuovi sviluppi di ext3 puoi visitare l'<uri
>link="https://listman.redhat.com/archives/ext3-users/">archivio della mailing
>list degli utenti di ext3</uri>. E puoi iscriverti <uri
>link="https://listman.redhat.com/mailman/listinfo/ext3-users">qui</uri>.
></p>
>
><p>
>Dai uno sguardo al tutorial di Daniel Robbins sulle <uri
>link="http://www-128.ibm.com/developerworks/edu/os-dw-linuxjfs-i.html">basi di
>JFS</uri> su developerWorks.
></p>
>
><p>
>Naviga <uri
>link="http://www-130.ibm.com/developerworks/linux/?article=lr">qui</uri> su
>developerWorks per maggiori risorse su Linux.
></p>
>
><p>
>Naviga <uri
>link="http://www-130.ibm.com/developerworks/opensource/?article=osr">qui</uri>
>su developerWorks per maggiori informazioni sull'Open Source.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>L'autore</title>
><section>
><body>
>
><p>
>Daniel Robbins abita ad Albuquerque in New Messico, Ã¨ il Presidente/CEO di
>Gentoo Technologies, Inc., l'ideatore di Gentoo Linux, un sistema Linux
>avanzato per PC, ed il sistema Portage, un sistema di port per Linux di nuova
>generazione. Ha contribuito come autore ai libri della Macmillan: Caldera
>OpenLinux Unleashed, SuSE Linux Unleashed e Samba Unleashed. Daniel Ã¨ stato
>coinvolto nel mondo dei computer in un certo qual modo dalla seconda elementare
>quando per la prima volta si imbattÃ© nel linguaggio di programmazione Logo ed
>assunse una dose potenzialmente pericolosa di Pac Man. Questo probabilmente
>spiega come mai Ã¨ stato impiegato come Lead Graphic Artist alla SONY Electronic
>Publishing/Psygnosis. A Daniel piace un sacco stare con sua moglie, Mary, e la
>loro figliola, Hadassah. Puoi metterti in contatto con Daniel all'indirizzo
><mail link="drobbins@gentoo.org">drobbins@gentoo.org</mail>.
></p>
>
></body>
></section>
></chapter>
>
></guide>

Actions: View

Attachments on bug 110455: 71421