Guida alla configurazione dei filesystem avanzati, Parte 8Devo 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'eccellente pagina di Andrew Morton "Using the ext3 filesystem in 2.4 kernels" (vedere Risorse 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. 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. 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. 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 Risorse). Linus la già aggiunta per voi. :) 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. 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. 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 Risorse). 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. 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. 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. Ora che ho spaventato le vostre menti, diamo una occhiata alle diverse opzioni di journaling di ext3. 4. Opzioni di journaling e latenza in scrittura Ext3 permette di scegliere uno tra tre modi di journaling quando si monta il filesystem: data=writeback, data=ordered, and data=journal. 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. 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 precedente articolo, 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. 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. 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. 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. 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:
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:
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).
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! 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. 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:
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. Abbiamo concluso l'articolo su ext3. Nel mio prossimo articolo esploreremo il magnifico... XFS!
|
|