<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>Software-RAID HOWTO: Domande sulle performance, sui tool e domande stupide in genere</TITLE>
<LINK HREF="Software-RAID-0.4x-HOWTO-9.html" REL=next>
<LINK HREF="Software-RAID-0.4x-HOWTO-7.html" REL=previous>
<LINK HREF="Software-RAID-0.4x-HOWTO.html#toc8" REL=contents>
</HEAD>
<BODY>
<A HREF="Software-RAID-0.4x-HOWTO-9.html">Avanti</A>
<A HREF="Software-RAID-0.4x-HOWTO-7.html">Indietro</A>
<A HREF="Software-RAID-0.4x-HOWTO.html#toc8">Indice</A>
<HR>
<H2><A NAME="s8">8. Domande sulle performance, sui tool e domande stupide in genere</A></H2>
<P>
<OL>
<LI><B>D</B>:
Ho creato un dispositivo RAID-0 con <CODE>/dev/sda2</CODE> e
<CODE>/dev/sda3</CODE>. Il dispositivo è molto più lento
di una singola partizione. Ma allora md è un ammasso di
robaccia?
<BLOCKQUOTE>
<B>R</B>:
Per usufruire di un dispositivo RAID-0 che funzioni alla
massima velocità, si devono utilizzare partizioni di
dischi differenti. Oltretutto, mettendo le due metà di
un mirror su di un solo disco non ci si cautela da
nessun tipo di malfunzionamento del disco.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Dove è la necessità di avere RAID-linear quando RAID-0 fa le stesse
cose con migliore efficienza?
<BLOCKQUOTE>
<B>R</B>:
Il fatto che RAID-0 abbia sempre una performance migliore non
è cosa ovvia; in effetti, in qualche caso, le cose potrebbero
andare peggio.
Il filesystem ext2fs distribuisce i file su tutta la partizione,
e cerca di mantenere contigui tutti i blocchi di un file,
nel tentativo di impedirne la frammentazione. Quindi ext2fs
si comporta "come se" ci fosse una striscia (di dimensioni
variabili) per ogni file. Se diversi dischi vengono concatenati
in un dispositivo RAID-linear, statisticamente i file verranno
distribuiti su ogni disco. Quindi, almeno per ext2fs, RAID-linear
si comporta in maniera molto simile a un RAID-0 con delle ampie
strisce. Al contrario RAID-0 con strisce piccole può causare
un'eccessiva attività del disco che può portare ad un forte
degrado delle prestazioni se si accede contemporaneamente
a diversi grandi file.
<P>In molti casi RAID-0 può risultare facile vincitore. Si immagini,
per esempio un grande file di database. Poiché ext2fs cerca
di raggruppare insieme tutti i blocchi di un file, vi sono buone
possibilità che esso finisca in un solo disco se si utilizza
RAID-linear o finisca diviso in molteplici strisce se si usa
RAID-0. Si immaginino adesso un certo numero di thread
(del kernel) che stanno tentando di accedere al database in
maniera casuale. Sotto RAID-linear tutti gli accessi finirebbero
con il dover essere soddisfatti da un solo disco che finirebbe
con l'essere inefficiente se paragonato alla possibilità di accessi
multipli paralleli che RAID-0 consente.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Come si comporta RAID-0 in una situazione nella quale le diverse
partizioni di stripe hanno dimensioni diverse? Le strisce vengono
distribuite uniformemente?
<BLOCKQUOTE>
<B>R</B>:
Per comprendere meglio aiutiamoci con un esempio che coinvolge
tre partizioni; una da 50Mb, una da 90Mb e una da 125Mb.
Chiamiamo D0 il disco da 50Mb, D1 il disco da 90Mb e D2 quello
da 125Mb. Quando si fa partire il dispositivo, il driver calcola
le 'strip zones' (letteralmente "zone di striscia". ndt). In questo
caso vengono individuate 3 zone, così definite:
<PRE>
Z0 : (D0/D1/D2) 3 x 50 = 150MB totali in questa zona
Z1 : (D1/D2) 2 x 40 = 80MB totali in questa zona
Z2 : (D2) 125-50-40 = 35MB totali in questa zona.
</PRE>
Si può notare come la dimensione totale delle zone sia la
dimensione del dispositivo virtuale, ma la distribuzione delle
strisce varia in funzione della zona. Z2 è inefficiente, poiché
contenuta in un solo disco.
Poiché <CODE>ext2fs</CODE> e molti altri filesystem di Unix
distribuiscono i file su tutto il disco, si ha il 35/265 =
13% di probabilità che i dati finiscano su Z2, e
quindi non beneficino dello striping.
(DOS cerca di riempire un disco partendo dall'inizio e
andando verso la fine e quindi i file più vecchi finirebbero
in Z0. Questo tipo di approccio porta però ad una
pesante frammentazione, e questo è il perché nessun altro
oltre a DOS gestisce il disco in questa maniera).
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Ho dei dischi di marca X e un controller di marca Y, sto
considerando se usare <CODE>md</CODE>.
Ma il throughput aumenta sensibilmente?
Le prestazioni sono notevolmente migliori?
<BLOCKQUOTE>
<B>R</B>:
La risposta dipende dalla configurazione che si usa.
<P>
<DL>
<DT><B>Prestazioni di Linux MD RAID-0 e RAID-linear:</B><DD><P>Se il sistema deve sopperire ad un alto numero di richieste
di I/O, statisticamente qualcuna andrà su un disco e
qualcun'altra su un altro. Quindi le prestazioni migliorano
rispetto ad un singolo disco. Ma il miglioramento effettivo
dipende molto dai dati, dalla dimensione delle strisce e da
altri fattori. In un sistema con basso carico di I/O le
prestazioni sono uguali a quelle di un singolo disco.
<P>
<DT><B>Prestazioni in lettura di Linux MD RAID-1(mirroring):</B><DD><P>MD implementa il bilanciamento in lettura. Quindi il codice
RAID-1 distribuirà il carico su ognuno dei dischi nel
mirror (due o più), effettuando operazioni alternate di
lettura da ognuno di essi. In una situazione con basso
carico di I/O questo non influisce per niente sulle
prestazioni: dovrete aspettare che un disco abbia finito
di leggere. Ma con due dischi in una situazioni di alto
carico di I/O la performance in lettura può raddoppiare
visto che le letture possono essere effettuate in parallelo
da ciascuno dei due dischi. Per N dischi nel mirror, la
prestazione può essere N volte migliore.
<P>
<DT><B>Prestazioni in scrittura di Linux MD RAID-1 (mirroring):</B><DD><P>Si deve attendere che la scrittura sia stata effettuata
su tutti i dischi del mirror. Questo a causa del fatto che
una copia dei dati deve essere scritta su ogni disco del
mirror. Quindi le prestazioni saranno quasi uguali a quelle
di un singolo disco in scrittura.
<P>
<DT><B>Prestazioni in lettura di Linux MD RAID-4/5:</B><DD><P>Statisticamente un dato blocco può trovarsi in un qualsiasi
disco di una serie, e quindi le prestazioni in lettura di
RAID-4/5 somigliano molto a quelle di RAID-0. Esse variano
in funzione dei dati, della dimensione delle strisce e del
tipo di utilizzo. Le prestazioni in lettura non saranno
buone quanto quelle di una serie di dischi in mirror.
<P>
<DT><B>Prestazioni in scrittura di Linux MD RAID-4/5:</B><DD><P>Questo sistema è in genere considerevolmente più lento
di un disco singolo. Questo a causa del fatto che la
parità dovrà essere scritta su un disco e i dati su
un altro. E per poter calcolare la nuova parità quella
vecchia e i vecchi dati devono prima essere letti. Viene
quindi effettuato un XOR fra i vecchi dati, i nuovi dati
e la vecchia parità: questo richiede numerosi cicli di CPU
e diversi accessi al disco.
</DL>
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Quale configurazione ottimizza le prestazioni di RAID?
<BLOCKQUOTE>
<B>R</B>:
Interessa più massimizzare il throughput o diminuire la latenza?
Non vi è una facile risposta dato il grande numero di fattori che
influenzano la performance:
<UL>
<LI>sistema operativo - l'accesso al disco è effettuato da
un solo processo o da più thread?</LI>
<LI>applicazioni - accedono ai dati in maniera
sequenziale o in maniera casuale?</LI>
<LI>file system - raggruppa i file o li distribuisce
(ext2fs raggruppa insieme i blocchi di un file e
distribuisce i file)</LI>
<LI>driver del disco - numero di blocchi di read ahead
(è un parametro impostabile)</LI>
<LI>hardware CEC - un drive controller o più?</LI>
<LI>hd controller - gestisce la coda di richieste
multiple? Ha una cache?</LI>
<LI>hard drive - dimensioni del buffer della
memoria cache -- è abbastanza ampia da gestire
la quantità e la velocità degli accessi in scrittura
di cui si ha bisogno?</LI>
<LI>caratteristiche fisiche del disco - blocchi per cilindro
-- accedere a blocchi su differenti cilindri porta il
disco ad effettuare molte operazioni di seek.</LI>
</UL>
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Quale è la configurazione di RAID-5 che ottimizza la performance?
<BLOCKQUOTE>
<B>R</B>:
Poiché RAID-5 genera un carico di I/O che è uniformemente
distribuito su diversi dischi, le prestazioni migliori si
otterranno quando il set RAID viene bilanciato usando
drive identici, controller identici e lo stesso (basso) numero
di drive su ciascun controller.
Si noti comunque che l'uso di componenti identici alzerà
la probabilità di malfunzionamenti multipli e simultanei
dovuti, per esempio a degli sbalzi repentini, al surriscaldamento
o a problemi di alimentazione durante un temporale.
Questo tipo di rischio può essere ridotto utilizzando dispositivi
di marca e modello differenti.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Quale è la dimensione ottimale di un blocco per un sistema RAID-4/5?
<BLOCKQUOTE>
<B>R</B>:
Nell'uso dell'implementazione attuale (Novembre 1997)
di RAID-4/5 è fortemente raccomandato che il filesystem
venga creato con <CODE>mke2fs -b 4096</CODE> al posto della
dimensione predefinita del blocco che è di 1024 byte.
<P>Questo perché l'attuale implementazione di RAID-5
alloca una pagina di memoria di 4K per ogni blocco del disco;
se un blocco del disco fosse grande solo 1K il 75%
della memoria allocata da RAID-5 per l'I/O non verrebbe
usata. Se la grandezza del blocco del disco è uguale a
quella della pagina di memoria il driver può (potenzialmente)
usare tutta la pagina. Quindi, su un filesystem con dei
blocchi da 4096 invece che da 1024, il driver RAID potrà
potenzialmente gestire una coda di richieste di I/O quattro
volte più grande senza usare memoria aggiuntiva.
<P>
<P><B>Nota</B>: le considerazioni precedenti non si applicano
ai driver Software RAID-0/1/linear.
<P>
<P><B>Nota:</B> le considerazioni sulla pagina di memoria da 4K
sono da applicare all'architettura Intel x86. Le dimensioni della
pagina di memoria su Alpha, Sparc e altre CPU sono differenti;
credo che siano 8k su Alpha/Sparc (????). Aggiustate le asserzioni
precedenti in maniera da tenerne conto.
<P>
<P><B>Nota:</B> se il vostro filesystem contiene un grande numero
di piccoli file (file più piccoli di 10KBytes), una frazione
considerevole di spazio disco andrà perduta. Questo a causa del
fatto che la dimensione dello spazio disco allocata dal filesystem
è un multiplo della dimensione del blocco. Allocare dei blocchi di
grosse dimensioni per dei piccoli file porta chiaramente ad uno
spreco di spazio disco; quindi si potrebbe voler continuare ad
utilizzare blocchi di piccole dimensioni, avere una una capacità
di immagazzinamento maggiore e non preoccuparsi della memoria
"persa" a causa del fato che le dimensioni della pagina
e del blocco non combaciano.
<P>
<P><B>Nota:</B> molti sistemi ''tipici'' non contengono così tanti
piccoli file. Comunque, anche se ci fossero centinaia di piccoli
file, questo potrebbe portare alla perdita di 10 - 100 MB di
spazio disco, che probabilmente è un compromesso accettabile
per avere buone prestazioni se si usano hard disk multi-gigabyte.
<P>Nel caso dei news server, ci potrebbero essere decine o centinaia
di migliaia di piccoli file. In questi casi i blocchi di
dimensioni minori, e quindi una maggiore capacità di
immagazzinamento, potrebbero essere più importanti dell'efficienza
dello scheduling di I/O.
<P>
<P><B>Nota:</B> esiste un filesystem sperimentale per Linux che
memorizza piccoli file e pezzi di file in un solo blocco.
Apparentemente questo influisce in maniera positiva sulla
performance quando la dimensione media dei file è molto più
piccola della dimensione del blocco.
<P>
<P>Nota: Le prossime versioni potrebbero implementare dei
dispositivi che renderanno obsolete queste discussioni.
Comunque sia la loro implementazione è difficoltosa a
causa del fatto che la allocazione dinamica a tempo di
esecuzione può portare a dei blocchi; l'implementazione
attuale effettua una pre-allocazione statica.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Quanto influenza la velocità del mio dispositivo RAID-0, RAID-4
o RAID-5 la grandezza del chunk (grandezza della striscia)?
<BLOCKQUOTE>
<B>R</B>:
La grandezza del chunk è la quantità di dati contigui nel
dispositivo virtuale che sono contigui anche nel dispositivo
fisico. In questo HOWTO "chunk" e "striscia" sono la stessa cosa:
quella che è comunemente chiamata "striscia" in altre
documentazioni su RAID, nelle pagine del manuale di MD
è chiamata "chunk". Si parla di strisce o chunk solo per
RAID 0, 4 e 5 poiché le strisce non vengono utilizzate nel
mirroring (RAID-1) e nella semplice concatenazione (RAID-linear).
Le dimensioni della striscia influenzano il tempo di latenza
(ritardo) nella lettura e nella scrittura, il throughput
(larghezza di banda) e la gestione di operazioni indipendenti
(l'abilità di provvedere a richieste di I/O simultanee che si
accavallano)
<P>Posto che si usino il filesystem ext2fs e le impostazioni attuali
del kernel che regolano il read-ahead, le strisce di grosse
dimensioni risultano quasi sempre essere una scelta migliore
rispetto a quelle di piccole dimensioni, e strisce di dimensioni
confrontabili con la grandezza di un quarto di cilindro del
disco potrebbero essere ancora migliori. Per capire questa
affermazione, consideriamo gli effetti delle strisce grandi
su file piccoli, e delle strisce piccole sui file grandi.
La dimensione delle strisce non influenza le prestazioni
durante la lettura di piccoli file: per una serie di N dischi
il file ha 1/N probabilità di essere interamente contenuto in una
striscia in uno dei dischi. Quindi sia la larghezza di banda che
la latenza in lettura sono comparabili a quelle di un singolo
disco. Ipotizzando il fatto che i file piccoli siano distribuiti
in maniera statisticamente uniforme nel filesystem (e, se si usa
il filesystem ext2fs, questo dovrebbe essere vero) il numero
delle letture simultanee sovrapposte può essere circa N volte
maggiore, senza collisioni significanti. Al contrario, se
vengono utilizzate strisce di dimensioni molto ridotte
e un file grande viene letto sequenzialmente, vi sarà un accesso
in lettura da ogni disco del sottosistema. Nella lettura di un
singolo file di grandi dimensioni, la latenza sarà almeno
raddoppiata, e la probabilità che un blocco si trovi molto
distaccato dagli altri aumenterà. Si noti comunque ciò che si
ottiene: la larghezza di banda può aumentare di al più N volte
nella lettura di un singolo file di grandi dimensioni, poiché
N dischi lo leggono simultaneamente (se viene usato il read-ahead
per mantenere attivi tutti i dischi). Ma vi è anche un effetto
secondario controproducente: se tutti i drive sono occupati nella
lettura di un singolo, grande file, il tentativo di leggere un
secondo, un terzo file allo stesso tempo causerà un grave
contenzioso, e degraderà le prestazioni a causa del fatto che
gli algoritmi del disco lo porteranno ad effettuare numerosi
seek. Quindi, strisce di grosse dimensioni danno quasi sempre
i risultati migliori. L'unica eccezione è costituita dalla
situazione nella quale si accede ad un singolo file di grandi
dimensioni e si richiede la maggiore larghezza di banda
possibile e si usa anche un buon algoritmo di read-ahead,
in questo caso sarebbero desiderabili strisce di piccole
dimensioni.
<P>
<P>
<P>Si noti che in precedenza questo HOWTO ha raccomandato
strisce di piccole dimensioni per i news spool o per altri
sistemi con un gran numero di piccoli file. Questo è stato
un cattivo consiglio, ed ecco perché: i news spool contengono
non solo molti piccoli file ma anche file sommario di grandi
dimensioni e grandi directory. Se il file sommario è più
grande della striscia, la sua lettura comporterà un accesso
su più dischi, rallentando il tutto come se ogni disco
effettuasse un seek. Similmente, l'attuale filesystem ext2fs
ricerca nelle directory in maniera lineare e sequenziale.
Quindi, per trovare un dato file o inode, in media metà della
directory verrà letta. Se la directory è distribuita su più
strisce (su più dischi), la lettura della directory (per es.
a causa del comando ls) potrebbe rallentare notevolmente.
Un grazie a Steven A. Reisman
<
<A HREF="mailto:sar@pressenter.com">sar@pressenter.com</A>> per questa correzione.
Steve ha anche aggiunto:
<BLOCKQUOTE>
Ho scoperto che l'uso di una striscia da 256k dà performance
molto migliori. Sospetto che la dimensione ottimale sia quella
di un cilindro del disco (o forse la dimensione della cache
dei settori del disco). Comunque sia, oggi i dischi hanno zone
di memorizzazione con un numero di settori variabile (e le cache
dei settori variano anche fra differenti modelli). Non c'è un
metodo per assicurarsi che le strisce non oltrepassino i
confini del cilindro.
</BLOCKQUOTE>
<P>
<P>
<P>I tool accettano le dimensioni delle strisce in KBytes.
Conviene specificare un multiplo della dimensione della
pagina per la CPU che si usa (4KB su x86).
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Quale è il corretto fattore di stride da usare nella creazione
di un filesystem ext2fs sulla partizione RAID? Per stride
intendo l'opzione -R nel comando <CODE>mke2fs</CODE>:
<PRE>
mke2fs -b 4096 -R stride=nnn ...
</PRE>
Cosa devo mettere al posto di nnn?
<BLOCKQUOTE>
<B>R</B>:
L'opzione <CODE>-R stride</CODE> viene usata per comunicare al
filesystem le dimensioni delle strisce RAID. Poiché solo
RAID-0,4 e 5 usano le strisce, e RAID-1 (mirroring) e RAID-linear
non le usano, questa opzione ha senso solo per RAID-0,4,5.
La conoscenza delle dimensioni delle strisce consente a
<CODE>mke2fs</CODE> di dimensionare i blocchi e i bitmap degli inode
in modo tale che non vengano a trovarsi tutti sullo stesso
dispositivo fisico. Uno sconosciuto ha contribuito alla
discussione scrivendo:
<BLOCKQUOTE>
L'ultima primavera ho notato che in una coppia di dischi
uno aveva sempre un I/O maggiore e ho attribuito la cosa
a questi blocchi di meta-dati. Ted ha aggiunto l'opzione
<CODE>-R stride=</CODE> in risposta alle mie spiegazioni e alla
richiesta di una soluzione.
</BLOCKQUOTE>
Per un filesystem con blocchi da 4Kb e strisce da 256Kb, si
potrebbe usare <CODE>-R stride=64</CODE>.
<P>Se non volete affidarvi all'opzione <CODE>-R</CODE>, potete ottenere
un effetto simile in modo differente. Steven A. Reisman
<
<A HREF="mailto:sar@pressenter.com">sar@pressenter.com</A>> scrive:
<BLOCKQUOTE>
Un'altra questione è l'uso del filesystem su un dispositivo RAID-0.
Il filesystem ext2 alloca 8192 blocchi per ogni gruppo. Ogni gruppo
ha il proprio set di inode. Se ci sono 2, 4, o 8 dischi questi
blocchi si accumulano nel primo disco. Ho distribuito gli inode
su tutti i drive impostando mke2fs in modo da allocare solo 7932
blocchi per gruppo.
</BLOCKQUOTE>
Qualche pagina di mke2fs non descrive l'opzione <CODE>[-g blocks-per-group]</CODE>
usata in questa operazione
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Dove posso mettere i comandi <CODE>md</CODE> negli script di avvio,
in modo tale che tutto parta automaticamente al boot?
<BLOCKQUOTE>
<B>R</B>:
Rod Wilkens
<
<A HREF="mailto:rwilkens@border.net">rwilkens@border.net</A>>
scrive:
<BLOCKQUOTE>
Quello che ho fatto è stato mettere ``<CODE>mdadd -ar</CODE>'' nel
``<CODE>/etc/rc.d/rc.sysinit</CODE>'' subito dopo il punto nel
quale il kernel carica i moduli, e prima del controllo dischi
di ``<CODE>fsck</CODE>''. In questa maniera si può mettere il
dispositivo ``<CODE>/dev/md?</CODE>'' in ``<CODE>/etc/fstab</CODE>''.
Quindi ho messo il comando ``<CODE>mdstop -a</CODE>'' subito dopo
il comando ``<CODE>umount -a</CODE>'' nel file
``<CODE>/etc/rc.d/init.d/halt</CODE>''.
</BLOCKQUOTE>
Nel caso si usi raid-5 si dovrà fare attenzione al codice
di uscita di <CODE>mdadd</CODE> e, nel caso indichi un errore,
eseguire
<BLOCKQUOTE><CODE>
<PRE>
ckraid --fix /etc/raid5.conf
</PRE>
</CODE></BLOCKQUOTE>
per riparare i danni.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Mi chiedo se sia possibile configurare lo striping su più di 2
dispositivi in <CODE>md0</CODE>? Questo per un news server, e io
ho 9 dischi... Non c'è bisogno che dica che ne servono molti più
di due. È possibile?
<BLOCKQUOTE>
<B>A</B>:
Si. (descrivere come)
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Quando Software RAID è superiore al RAID Hardware?
<BLOCKQUOTE>
<B>R</B>:
Normalmente il RAID hardware è considerato superiore al RAID
Software, poiché i controller hardware dispongono spesso di una
capiente cache e possono effettuare una programmazione migliore
delle operazioni in parallelo. Comunque il software RAID integrato
può (e lo fa) avvantaggiarsi della sua integrazione con il sistema
operativo.
<P>Per esempio, ... ummm. Oscura descrizione del caching
dei blocchi ricostruiti nella cache del buffer tralasciata ...
<P>
<P>È stato riferito che, su un sistema SMP con doppio PPro,
software RAID supera le prestazioni di un hardware RAID di ben
nota marca di un fattore variabile da 2 a 5.
<P>
<P>Software RAID è anche un'opzione molto interessante per
sistemi server ridondanti ad altro gradi di affidabilità.
In questa configurazione due CPU sono collegate ad un set
di dischi SCSI. Se un server si blocca o non risponde più
l'altro server può eseguire <CODE>mdadd</CODE>, <CODE>mdrun</CODE>
e <CODE>mount</CODE> per montare la serie di dischi RAID,
e continuare le operazioni. Questo tipo di operazione
a doppio controllo non è sempre possibile con molti
controller RAID, a causa del fatto che il controller
hardware mantiene la stessa configurazione.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Se aggiorno la mia versione di raidtools, posso avere problemi
nella gestione di vecchi sistemi? In breve, devo ricreare i miei
sistemi RAID ogni volta che aggiorno i programmi di utilità raid?
<BLOCKQUOTE>
<B>R</B>:
No, a meno che non cambi il numero primario di versione.
Una versione di MD x.y.z consiste di tre sottoversioni:
<PRE>
x: Versione primaria.
y: Versione secondaria.
z: Livello di patch.
</PRE>
La versione x1.y1.z1 del driver RAID supporta un sistema RAID
con versione x2.y2.z2 nel caso (x1 == x2) e (y1 >= y2).
Le versioni che differiscono per il solo livello di patch (z) sono
concepite in modo da essere compatibili.
<P>Il numero di versione secondario viene incrementato quando la
struttura del sistema RAID viene modificata in modo tale da
renderla incompatibile con le vecchie versioni del driver. Le
nuove versioni del driver manterranno la compatibilità con i
vecchi sistemi RAID.
<P>Il numero primario di versione viene incrementato quando non
vi sono più ragioni per continuare a supportare i vecchi sistemi
RAID nel nuovo codice del kernel.
<P>
<P>Per quanto riguarda RAID-1, è improbabile che la struttura del
disco o dei superblock venga alterata entro breve termine.
Le ottimizzazioni e le nuove funzioni (ricostruzione, tool
che implementino il multithread, hot-plug ecc.) non vanno
a modificare la struttura fisica.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Il comando <CODE>mdstop /dev/md0</CODE> dice che il dispositivo è occupato.
<BLOCKQUOTE>
<B>R</B>:
C'è un processo che ha un file aperto su <CODE>/dev/md0</CODE> o
<CODE>/dev/md0</CODE> è ancora montato. Chiudere il processo o
eseguire <CODE>umount /dev/md0</CODE>.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Vi sono dei tool per l'analisi delle prestazioni?
<BLOCKQUOTE>
<B>R</B>:
Vi è anche un nuovo programma di utilità chiamato <CODE>iotrace</CODE>
nella directory <CODE>linux/iotrace</CODE>. Esso legge <CODE>/proc/io-trace</CODE>
e analizza/riporta il suo output. Se credete che le prestazioni
dei vostri dispositivi a blocchi siano poco convincenti, date
un'occhiata all'output di iotrace.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Leggendo i sorgenti di RAID ho visto il valore <CODE>SPEED_LIMIT</CODE>
impostato a 1024K/sec. Che significa? Questo rallenta le prestazioni?
<BLOCKQUOTE>
<B>R</B>:
<CODE>SPEED_LIMIT</CODE> viene usato per regolare la ricostruzione
RAID quando essa avviene in automatico. Semplificando, la
ricostruzione automatica permette di effettuare <CODE>e2fsck</CODE>
e <CODE>mount</CODE> subito dopo uno shutdown sporco, senza prima
dover eseguire <CODE>ckraid</CODE>. La ricostruzione automatica
viene usata anche dopo la sostituzione di un disco rotto.
<P>Per evitare un sovraccarico del sistema mentre la ricostruzione
è in corso, il processo di ricostruzione controlla la velocità
alla quale essa avviene e la rallenta se è troppo veloce.
Il limite di 1M/sec è stato scelto arbitrariamente come ragionevole
velocità che consente alla ricostruzione di finire in un tempo
accettabile, con solo un leggero carico del sistema, in modo
tale che gli altri processi non vengano disturbati.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
E riguardo la ''spindle synchronization'' o ''disk synchronization''
("sincronizzazione dei dischi". ndt)?
<BLOCKQUOTE>
<B>R</B>:
La sincronizzazione dei dischi viene usata per far girare
più hard disk esattamente alla stessa velocità, in modo tale
che le loro superfici siano sempre perfettamente allineate.
Questo metodo viene usato da qualche controller hardware
per migliorare l'organizzazione degli accessi in scrittura.
Tuttavia, per quanto riguarda Software RAID, questa informazione
non viene usata e la sincronizzazione dei dischi può addirittura
influire negativamente sulle prestazioni.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Come posso creare degli spazi di swap usando raid 0?
Lo stripe delle aree di swap su più di 4 dischi è realmente
veloce?
<BLOCKQUOTE>
<B>R</B>:
Leonard N. Zubkoff risponde:
È veramente veloce, ma non c'è necessità di usare MD per
mettere in strip le aree di swap. Il kernel usa automaticamente
le strisce su diverse aree di swap a priorità uguale. Per esempio,
la seguente configurazione di <CODE>/etc/fstab</CODE> mette in stripe
le aree di swap su cinque drive suddivisi in tre gruppi:
<PRE>
/dev/sdg1 swap swap pri=3
/dev/sdk1 swap swap pri=3
/dev/sdd1 swap swap pri=3
/dev/sdh1 swap swap pri=3
/dev/sdl1 swap swap pri=3
/dev/sdg2 swap swap pri=2
/dev/sdk2 swap swap pri=2
/dev/sdd2 swap swap pri=2
/dev/sdh2 swap swap pri=2
/dev/sdl2 swap swap pri=2
/dev/sdg3 swap swap pri=1
/dev/sdk3 swap swap pri=1
/dev/sdd3 swap swap pri=1
/dev/sdh3 swap swap pri=1
/dev/sdl3 swap swap pri=1
</PRE>
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Voglio ottimizzare le prestazioni. Devo usare controller
multipli?
<BLOCKQUOTE>
<B>R</B>:
In molti casi la risposta è si. L'uso di controller
multipli per accedere in parallelo al disco consentirà
un incremento delle prestazioni. Ovviamente il miglioramento
effettivo dipenderà dalla vostra particolare configurazione.
Per esempio è stato riferito (Vaughan Pratt, gennaio 98)
che un singolo Cheetah da 4.3Gb collegato ad un Adaptec
2940UW può arrivare ad un trasferimento di 14Mb/sec (senza
l'uso di RAID). Installando due dischi su un controller e
usando una configurazione RAID-0 si arriva ad una prestazione
di 27Mb/sec.
<P>Si noti che il controller 2940UW è un controller SCSI
"Ultra-Wide", capace di un trasferimento teorico di 40Mb/sec.
quindi la velocità di trasferimento misurata non sorprende.
Tuttavia un controller più lento collegato a due dischi
veloci potrebbe fare da collo di bottiglia. Si noti anche che
molte periferiche SCSI out-board (ad es. i tipi con le
connessioni utilizzabili "a caldo") non possono arrivare
a 40Mb/sec a causa del rumore elettrico e di quello dovuto al
cablaggio.
<P>
<P>
<P>Se state progettando un sistema a controller multipli
tenete a mente il fatto che molti dischi e molti controller
funzionano normalmente al 70-85% della loro velocità
massima.
<P>
<P>Si noti anche che l'uso di un controller per disco può ridurre
la probabilità che il sistema si blocchi a causa di un
malfunzionamento dei cavi o del controller (Teoricamente
-- questo accade solo nel caso in cui il driver del
controller riesca a gestire ordinatamente un controller rotto.
Non tutti i device driver SCSI sembrano riuscire a gestire
una simile situazione senza andare in panico o bloccarsi in
altra maniera).
</BLOCKQUOTE>
</LI>
</OL>
<HR>
<A HREF="Software-RAID-0.4x-HOWTO-9.html">Avanti</A>
<A HREF="Software-RAID-0.4x-HOWTO-7.html">Indietro</A>
<A HREF="Software-RAID-0.4x-HOWTO.html#toc8">Indice</A>
</BODY>
</HTML>
