Attachment 73171 Details for Bug 112979 – [it] translated l-afig-p8.xml

[it] translated l-afig-p8.xml

l-afig-p8.xml (text/plain), 17.54 KB, created by Danilo Bazzani on 2005-11-19 03:03:54 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Danilo Bazzani

Created: 2005-11-19 03:03:54 UTC

Size: 17.54 KB

patch

obsolete

><?xml version='1.0' encoding='UTF-8'?>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>
>
><guide link="/doc/in/articles/l-afig-p8.xml" disclaimer="articles">
>
><title>Guida alla configurazione dei filesystem avanzati, Parte 8</title>
>
>
>
><author title="Autore">
><mail link="drobbins@gentoo.org">Daniel Robbins</mail>
></author>
>
><author title="Traduttore">
> <mail link="">Team Italiano</mail>
></author>
>
>
>
>
><abstract>
>Con la versione 2.4 di Linux molti nuovi filesystem sono possibili, inclusi Reiserfs, XFS, GFS, ed altri. Questi file system sono spettacolari, ma cosa fanno esattamente, a cosa servono, come devono essere utilizzati esattamente con sicurezza in un ambiete produttivo? Daniel Robbins risponde a queste domande mostrando come configurare questi nuovi filesystem avanzati sotto Linux 2.4. In questo articolo, Daniel continua descrivendo ext3, una nuova versione migliorata di ext2 con possibilitÃ  di journaling. Rivela tutte le informazioni interne di ext3, e dimostra alcune ottime prestazioni con ext3 data=journal.
></abstract>
>
><version>1.1</version>
><date>2005-10-09</date>
>
><chapter>
><title>Introduzione</title>
><section>
><body>
><p>
>Devo essere onesto. Per questo articolo, avevo pianificato di mostrare come ottenere ed utilizzare ext3. Anche se Ã¨ quello che pensavo di fare, non lo farÃ². L'eccelente pagina di Andrew Morton "Using the ext3 filesystem in 2.4 kernels" (vedere <uri link="#resources">Risorse</uri> in fondo a questo articolo) fa giÃ  una ottima descrizione su come abilitare ext3 sul vostro sistema, cosÃ¬ non Ã¨ necessario che io ripeta qui tutte le basi. Invece, cercherÃ² di affrontare alcuni argomenti interessanti, che penso troverete molto utili. Dopo aver letto questo articolo, quando sarete pronti per ottenere ed installare ext3, andate alla pagina di Andrew.
></p>
></body>
></section>
></chapter>
>
><chapter>
><title>Aggiornare al kernel 2.4</title>
><section>
><body>
><p>
>Inanzitutto, iniziamo con un aggiornamento alla versione 2.4 del kernel. Ho gia discusso la stabilitÃ  del kernel quando ho affrontato ReiserFS. In quel periodo, trovare un kernel 2.4 stabile era una sfida, ed io raccomandavo di tuilizzare il kernel 2.4.4-ac9 -- specialmente per coloro che pianificavano di usare il filesystem ReiserFS in un ambiente produttivo. Come si puÃ² immaginare, molto Ã¨ accaduto dal 2.4.4-ac9, ed Ã¨ sicuramente il momento di guardare ai kernel piÃ¹ nuovi.
></p>
>
><p>
>Con il kernel 2.4.10, la serie 2.4 raggiunge un nuovo livello di prestazioni e scalabilitÃ  (qualcosa che Ã¨ stata prevista da lungo tempo). Cosi, che cosa a permesso a Linux 2.4 di crescere? Con un acronimo, VM. Linus, riconoscendo che la serie 2.4 non aveva prestazioni spettacolari, ha tolto il codice complesso della VM di Linux e lo ha sostituito con una magra VM realizzata da Andrea Michelangeli,. La nuova VM realizzata da Andrea (che appare per la prima volta nel 2.4.10) Ã¨ davvero starordinaria; la nuova VM ha realmente accelerato il kernel e reso l'intero sistema piÃ¹ reattivo. Il kernel 2.4.10 Ã¨ definitivamente una svolta importante nello sviluppo del kernel; fino ad allora, le cose non andavano molto bene, e molti si domandavano perchÃ¨ non erano sviluppatori di FreeBSD. Noi tutti dovremmo ringraziare Linus per il suo eroismo (ma Ã¨ stato necessario irritarlo) nel fare un cambiamento cosi importante nella serie stabile del kernel.
></p>
>
><p>
>PoichÃ© il nuovo codice della VM di Andrea ha avuto bisogno di un po' di tempo per essere ben integrato con il resto del kernel, Ã¨ meglio utilizzare un 2.4.13+. Ancora meglio Ã¨ utilizzare un 2.4.16+, poichÃ© il codice del solido filesystem ext3 Ã¨ finalmente integrato nel kernel di Linus a partire dalla 2.4.15-pre2. Non ci sono motivi per evitare di utilizzare versioni piÃ¹ recenti del kernel, e renderÃ  il lavoro di ottenere ext3 in servizio molto piÃ¹ facile. Se un kernel 2.4.16+ Ã¨ utilizzato, bisogna ricordare che non Ã¨ piÃ¹ necessario utilizzare la patch per ext3 come descritto nella pagina di Andrew (vedere <uri link="#resources">Risorse</uri>). Linus la giÃ  aggiunta per voi. :)
></p>
>
><p>
>Noterete che raccomando di utilizzare 2.1.16+ invece che 2.4.15+, e con buoni motivi. Con la versione 2.4.15-pre9, un brutto bug era stato introdotto nel kernel. Il bug non Ã¨ stato risolto fino all 2.4.16-pre1 per problemi nell'identificare e risolvere il problema, con il risultato che tutta una serie di kernel (compreso il 2.4.15) non dovrebbero essere utilizzati in nessun caso. Scegliere un kernel 2.4.16+ permette di evitare interamente questo lotto difettoso.
></p>
></body>
></section>
></chapter>
>
><chapter>
><title>Laptop...fate attenzione?</title>
><section>
><body>
><p>
>Ext3 ha la grande reputazione di essere un solido filesystem, cosi Ã¨ sorprendente scorprire che non pochi utilizzatori di laptop hanno avuto problemi di corruzione quando sono passati a ext3. In generale, si sta tentando di reaglire a questo tipo di rapporti evitando ext3 interamente; tuttavia, dopo aver chiesto in giro, ho scoperto che i problemi di corruzione che le persone affrontavano non aveva niente a che fare con ext3, ma erano causati da alcuni hard-disk dei laptop.
></p>
></body>
></section>
>
><section>
><title>La "write cache"</title>
><body>
><p>
>Voi potreste non saperlo, ma i piÃ¹ moderni hard-disk hanno qualcosa chiamata "write cache", usata dall'hard-disk per raccogliere le operazioni di scrittura in attesa. Mettendo le operazioni di scrittura in una cache, il firmware dell'hard-disk puÃ² riordinare e raggrupparle cosicchÃ¨ loro possono essere scritte sul disco il piÃ¹ velocemente possibile. La "write cache" Ã¨ generalmente considerata una ottima idea (leggere la spiegazione e l'opinione di Linus sulla "write cache" in <uri link="#resources">Risorse</uri>).
></p>
>
><p>
>Sfortunatamente, certi hard-disk per laptop ora in vendita hanno la deprecabile caratteristica di ignorare tutte le richieste ufficiali ATA per utilizzare la "write cache" sul disco. Questa non Ã¨ una magnifica caratteristica di progetto, anche se Ã¨ stata permessa dalle specifiche ATA recentemente. Con questi tipi di dischi, non c'Ã¨ modo per il kernel di garantire che un particolare blocco Ã¨ stato attualmente registrato su un piatto del disco. Anche se questo suona come un problema spinoso, questo problema particolare da sÃ¨ non Ã¨ probabilmente la causa dei problemi di corruzione di dati che le persone hanno sperimentato.
></p>
>
><p>
>Comunque, c'Ã¨ di peggio. Alcuni moderni hard-disk per laptop hanno la pessima abitudine di gettare via la loro "write cache" tutte le volte che il sistema Ã¨ sospeso o riavviato. Ovviamente, se un hard-disk ha entrambi questi problemi, corromperÃ  regolarmente i dati, e non c'Ã¨ niente che Linux possa fare per impedire che succeda.
></p>
>
><p>
>Qual Ã¨ la soluzione? Se voi avete un laptop, siate attenti. Fate un back-up di tutti i vostri file importanti prima di fare qualsiasi grande cambiamento al vostro filesystem. Se i vostri problemi di corruzione di dati sembrano del tipo descritto precedentmente, in particolare con ext3, ricordate che potrebbe essere il vostro hard-disk ad essere colpevole. In quel caso, voi dovreste contattare il produttore del laptop e domandare come poter sostituire l'hard-disk.  
>Si spera, nel giro di qualche mese, che questi hard-disk saranno ritirati dal mercato e non dovremo piÃ¹ preoccuparci ancora di queste note.
></p>
>
><p>
>Ora che ho spaventato le vostre menti, diamo una occhiata alle diverse opzioni di journaling di ext3.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Opzioni di journaling e latenza in scrittura</title>
><section>
><body>
>
><p>
>Ext3 permette di scegliere uno tra tre modi di journaling quando si monta il filesystem: data=writeback, data=ordered, and data=journal.
></p>
>
><p>
>Per specificare un modo di journaling, Ã¨ possibile aggiungere l'appropriata stringa (data=journal, per esempio) nella sezione delle opzioni in /etc/fstab, o specificando -o data=journal come opzione quando monta direttamente dalla riga di comando. Se si vuole definire il metodo di journaling dei dati da utilizzare per il filesystem di root (data=ordered Ã¨ l'opzione predefinita), si deve utilizzare un kernel di boot speciale chiamato rootflags. Cosi, Se si desidera utilizzare un modo di journaling completo per il filesystem di root, aggiungere rootflags=data=journal nelle opzioni del kernel di boot.
></p>
>
></body>
></section>
><section>
><title>Il modo data=writeback</title>
><body>
>
><p>
>Con il modo data=writeback, ext3 non fa nessun journaling dei dati, fornendo un journaling simile a quello trovato nei filesystem XFS, JFS e ReiserFS (solo metadati). Come ho spiegato nel <uri link="http://www-128.ibm.com/developerworks/linux/library/l-fs7.html">precedente articolo</uri>, questo potrebbe permettere che un file appena modificato diventi corrotto nel caso di un inaspettato riavvio. Nonostante questo svantaggio, il modo data=writeback offre la miglior prestazione in molte condizioni. 
></p>
>
></body>
></section>
><section>
><title>Il modo data=ordered</title>
><body>
>
><p>
>Con il modo data=ordered, ext3 esegue ufficialmente il journaling dei metatdata, ma raggruppa logicamente i blocchi di dati e di metadata in una singola unitÃ  denominata una transazione. quando Ã¨ il momento di scrivere i nuovi metadata, i blocchi di dati associati sono scritti prima. Il modo data=ordered effettivamente risolve i problemi di corruzione del modo data=writeback e degli altri metodi di journaling dei filesystem, senza richiedere il journaling completo di tutti i dati. In generale, data=ordered per un filesistem ext3 ha prestazioni leggermente piÃ¹ lentedi un filesystem con data=writeback, ma significativamente piÃ¹ veloce di un journaling eseguito su tutti i dati.
></p>
>
><p>
>Quando si aggiungono dati aui file, il modo data=ordered garantisce tutta l'integrita offerta dal modo di journaling completo di ext3. Tuttavia, se parte di un file sta per essere riscritta e il sistema ha un crash, Ã¨ possibile che la parte in scrittura contenga una combinazione dei blocchi originali mischiata con quelli aggiornati. Questo perchÃ¨ data=ordered non fornisce garanzie su quali blocchi vengano riscritti prima, cosi non si puÃ² assumere che se il blocco x Ã¨ stato aggiornato, sia stato aggiornato anche il blocco x-1. Invece, data=ordered lascia la scelta dell'ordine di scrittura alla "write cache" dell'hard-disk. In generale, questa limitazione non ha un impatto negativo sulle persone molto spesso, poichÃ¨ i nuovi file sono molto piÃ¹ comuni di quelli sovrascritti. Per questa ragione, il modo data=ordered Ã¨ un ottimo sostituto (e con migliori prestazioni) di un journaling completo dei dati. 
></p>
>
></body>
></section>
><section>
><title>il modo data=journal</title>
><body>
>
><p>
>Il modo data=journal fornisce il journaling dei dati e dei metadati, Tutti i nuovi dati sono scritti prima sul journal , e dopo nella sua posizione finale. Nel caso di un crash, il journal puÃ² essere rifatto, mantenendo sia i dati che i metadati in uno stato coerente.
></p>
>
><p>
>Teoricamente, il modo data=journal Ã¨ il piÃ¹ lento tar tutti i modi di journaling, poichÃ¨ i dati vengono scritti due volte anzichÃ¨ una. Tuttavia, Ã¨ dimostrato che in certe situazioni, il modo data=journal puÃ² essere incredibilmente veloce. Andrew Morton, dopo aver letto un rapporto su LKML (Linux Kernel Mailing List) nel quale il filesystem ext3 data=journal era descritto dalle persone come un filesystem interattivo dalle prestazioni incredibili, decise di mettere i atto unpiccolo test. Inanzitutto, ha creato un sempliche script di shell progettato per scrivere sul filesystem il piÃ¹ velocemente possibile:
></p>
>
><pre caption="Scrittura veloce">
>while true
>do
>        dd if=/dev/zero of=largefile bs=16384 count=131072
>done
></pre>
>
><p>
>Mentre i dati stavo per essere scritti sul filesystem di prova, cercava di leggere 16MB di dati da un altro filesystem ext2 sullo stesso disco, cronometrando i risultati:
></p>
>
><pre caption="Leggere un file di 16MB">
><i>$ time cat 16-meg-file > /dev/null</i>
></pre>
>
><p>
>I risultati erano sbalorditivi. Il modo data=journal permetteva di di leggere il file di 16MB dalle 9 alle 13 volte piÃ¹ velocemente di un filesystem ext3 con modo diverso, ReiserFS ed anche ext2 (che non ha il journaling).
></p>
>
><table>
><tr>
>  <ti>Scrittura su filesystem</ti>
>  <ti>tempo di lettura del file da 16MB (secondi)</ti>
></tr>
><tr>
>  <ti>ext2</ti>
>  <ti>78</ti>
></tr>
><tr>
>  <ti>ReiserFS</ti>
>  <ti>67</ti>
></tr>
><tr>
>  <ti>ext3 data=ordered</ti>
>  <ti>93</ti>
></tr>
><tr>
>  <ti>ext3 data=writeback</ti>
>  <ti>74</ti>
></tr>
><tr>
>  <ti>ext3 data=journal</ti>
>  <ti><c>7</c></ti>
></tr>
></table>
>
><p>
>Andrew riprovÃ² questo test, ma cercando di leggere il file da 16MB dal filesystem di test (invece che da un filesystem differente), ed ottenne lo stesso identico risultato. Cosi, Cosa significa? In qualche modo, un filesystem ext3 con modo data=journal Ã¨ incredibilmente molto adatto in quelle situazione durante le quali Ã¨ necessario scrivere e leggere dati contemporaneamente. PerciÃ², un filesystem ext3 con modo data=journal, che Ã¨ indicato come il piÃ¹ lento di tutti i modi per ext3 in quasi tutte le condizioni, attualmente dimostra di avere le migliori prestazioni per condizioni impegnative nelle quali le operazioni di IO contemporanee devono essere ottimizzate. Potrebbe essere che il modo data=journal non sia piÃ¹ lento dopo tutto!
></p>
>
><p>
>Andrew sta ancora cercando di capire esattamente perchÃ¨ il modo data=journal sia meglio di tutti gli altr. Quando capirÃ , egli potrebbe essere in grado di aggiungere la necessaria modifica al resto di ext3 cosi che anche i modi data=writeback e data=ordered migliorino.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Modifiche per data=journal</title>
><section>
><body>
>
><p>
>Alcune persone hanno particolari problemi di prestazioni quando usano il modo data=journal con ext3 su server sovraffollati - server NFS, in particolare. Ogni trenta secondi secondi, il server ha una enorme attivitÃ  di scrittura, che spinge il sistema vicino all'arresto. Se questo problema accade, Ã¨ facile da risolvere. Semplicemente eseguite il seguente comando come root per modificare l'algoritmo di pulizia del buffer pieno:
></p>
>
><pre caption="Modificare bdflush">
><i>$ echo 40 0 0 0 60 300 60 0 0 > /proc/sys/vm/bdflush</i>
></pre>
>
><p>
>Queste nuove impostazioni di bdflush faranno eseguire kupdate ogni 0.6 secondi invece che ogni 5 secondi. Inoltre, indicheranno al kernel di pulire il buffer pieno dopo 3 secondi invece che ogni 30, come predefinito. Ripulendo sul disco le modifiche dei dati piÃ¹ regolarmente, quelle enormi attivitÃ  di scrittura dovrebbero essere evitate. Questa via sarÃ  leggermente meno efficiente, poichÃ¨ il kernel troverÃ  meno opportunitÃ  di combinare traloro le scritture. Ma per un server sovraffollato, le scritture saranno piÃ¹ consistenti e le prestazioni fortemente migliorate.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Conclusioni</title>
><section>
><body>
>
><p>
>Abbiamo concluso l'articolo su ext3. Nel mio prossimo articolo esploreremo il magnifico... XFS!
></p>
>
></body>
></section>
></chapter>
>
><chapter id="resources">
><title>Risorse</title>
><section>
><body>
>
>
>
><ul>
>  <li>
>    Controlla <uri link="http://www.zip.com.au/~akpm/linux/ext3/ext3-usage.html">la pagina su ext3 e linux 2.4</uri> di Andrew Morton per completare le impostazioni di ext3.
>  </li>
>  <li>
>    Scopri di piÃ¹ su l'uso di ext3 e linux 2.4 alla <uri link="http://www.zip.com.au/~akpm/linux/ext3/">pagina</uri> di Andrew Morton.
>  </li>
>  <li>
>    Impara di piÃ¹ sugli strani problemi di corruzione degli hard-disk dei lapotop leggendo <uri link="http://www.kerneltraffic.org/kernel-traffic/kt20011015_137.html">Kernel Traffic's summary</uri>.
>  </li>
>
>
>  <li>
>    Per conoscere gli ultimi sviluppi di ext3, visita sicuramente l'archivio della mailing list <uri link="https://listman.redhat.com/pipermail/ext3-users/">ext3-users</uri>. Naturalmente, puoi anche <uri link="https://listman.redhat.com/mailman/listinfo/ext3-users">abbonarti</uri>.
>  </li>
>
></ul>
>
></body>
></section>
></chapter>
></guide>

Actions: View

Attachments on bug 112979: 73171