<!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: Considerazioni sul setup e sull'installazione</TITLE>
<LINK HREF="Software-RAID-0.4x-HOWTO-4.html" REL=next>
<LINK HREF="Software-RAID-0.4x-HOWTO-2.html" REL=previous>
<LINK HREF="Software-RAID-0.4x-HOWTO.html#toc3" REL=contents>
</HEAD>
<BODY>
<A HREF="Software-RAID-0.4x-HOWTO-4.html">Avanti</A>
<A HREF="Software-RAID-0.4x-HOWTO-2.html">Indietro</A>
<A HREF="Software-RAID-0.4x-HOWTO.html#toc3">Indice</A>
<HR>
<H2><A NAME="s3">3. Considerazioni sul setup e sull'installazione</A></H2>
<P>
<OL>
<LI><B>D</B>:
Quale è il modo migliore di configurare Software RAID?
<BLOCKQUOTE>
<B>R</B>:
Continuamente riscopro il fatto che la pianificazione del
file-system è uno dei lavori più difficili sotto Unix. Per
rispondere alla domanda, posso descrivere cosa si può fare.
Supponiamo il setup che segue:
<UL>
<LI>2 dischi EIDE, da 2.1 Gb ciascuno.
<BLOCKQUOTE><CODE>
<PRE>
disco partizione montata su dimensione dispositivo
1 1 / 300M /dev/hda1
1 2 swap 64M /dev/hda2
1 3 /home 800M /dev/hda3
1 4 /var 900M /dev/hda4
2 1 /root 300M /dev/hdc1
2 2 swap 64M /dev/hdc2
2 3 /home 800M /dev/hdc3
2 4 /var 900M /dev/hdc4
</PRE>
</CODE></BLOCKQUOTE>
</LI>
<LI>Ogni disco è su un controller (e cavo) separato.
La mia teoria è che un guasto al controller o al cavo
non manderà in tilt tutti e due i dischi. Questo
permette un miglioramento delle performance rispetto
alla gestione di operazioni parallele
</LI>
<LI>Installare Linux su (<CODE>/</CODE>) della partizione
<CODE>/dev/hda1</CODE>. Marcare questa partizione come
avviabile.
</LI>
<LI><CODE>/dev/hdc1</CODE> conterrà una copia ``fredda'' di
<CODE>/dev/hda1</CODE>. Questa non è una copia RAID,
è proprio una semplice copia. Serve solamente nel
caso che il primo disco si rompa; si può usare un disco,
di recupero, marcare <CODE>/dev/hdc1</CODE> come avviabile, e
usare questa partizione per continuare a lavorare senza
dover reinstallare il sistema. Può anche essere utile
mettere una copia del kernel di <CODE>/dev/hdc1</CODE> su
LILO per semplificare il boot in caso di malfunzionamento.
Qui si suppone che nel caso di un grave malfunzionamento
si possa ancora far partire il sistema senza preoccupazioni
riguardanti la corruzione dei superblock raid o di altri
errori del raid che non si capiscono.
</LI>
<LI><CODE>/dev/hda3</CODE> e <CODE>/dev/hdc3</CODE> saranno il mirror
<CODE>/dev/md0</CODE>.</LI>
<LI><CODE>/dev/hda4</CODE> e <CODE>/dev/hdc4</CODE> saranno il mirror
<CODE>/dev/md1</CODE>.
</LI>
<LI>abbiamo scelto<CODE>/var</CODE> e <CODE>/home</CODE> per essere
mirrorate in partizioni separate, seguendo questa logica
<UL>
<LI><CODE>/</CODE> (la partizione root) conterrà
dati relativamente statici, non soggetti a
cambiamenti. Ad ogni effetto sarà si sola lettura
anche se non sarà impostata e montata veramente
in sola lettura
</LI>
<LI><CODE>/home</CODE> conterrà i dati che cambiano
"lentamente".</LI>
<LI><CODE>/var</CODE> conterrà i dati che cambiano
rapidamente, inclusi i mail spool, i database
ed i log del web server.</LI>
</UL>
L'idea che sta dietro all'uso di più partizioni
separate è che <B>se</B>, per qualche bizzarra,
ragione che sia un errore umano, un calo di tensione, o
altro il sistema operativo impazzisce, il danno è limitato
ad una sola partizione. In un caso tipico vi è un calo di
tensione mentre il sistema sta scrivendo sul disco. Questo
lascerà sicuramente il file system in uno stato di
inutilizzabilità, a cui sarà posto rimedio da <CODE>fsck</CODE>
nel boot seguente. Anche se <CODE>fsck</CODE> farà del suo
meglio per rimettere a posto la situazione evitando di fare
ulteriori danni, è confortante sapere che ogni danno è
stato limitato ad una sola partizione. In un altro caso
tipico l'amministratore di sistema fa un errore durante
le operazioni di recupero del file system, cosa che porta
alla cancellazione o alla distruzione dei dati.
L'uso delle partizioni può aiutare a contenere le
ripercussioni degli errori dell'operatore. </LI>
<LI>Un'altra scelta ragionevole per la disposizione
delle partizioni potrebbe essere quella di <CODE>/usr</CODE>
o di <CODE>/opt</CODE>. In effetti, <CODE>/opt</CODE> e
<CODE>/home</CODE> sono una buona scelta come partizioni
RAID-5, se si hanno più hard disk. Una parola sulla
prudenza da utilizzare: <B>NON</B> mettere <CODE>/usr</CODE> in una
partizione RAID-5. Se si avesse un grave malfunzionamento
si potrebbe scoprire che non si può montare <CODE>/usr</CODE>,
e che si ha bisogno di qualche strumento che vi risiede
(ad es. i programmi per la rete, o il compilatore.)
Con RAID-1, se si ha un malfunzionamento e RAID smette
di funzionare, si può almeno montare uno dei due mirror.
La stessa cosa non si può fare con ogni altro livello RAID
(RAID-5, striping, linear RAID). </LI>
</UL>
<P>Così, per rispondere alla domanda:
<UL>
<LI>installare il S.O. sul disco 1, partizione 1.
NON montare altre partizioni. </LI>
<LI>installare RAID seguendo le istruzioni. </LI>
<LI>configurare <CODE>md0</CODE> e <CODE>md1</CODE>.</LI>
<LI>convincersi del fatto che si sa che
cosa fare in caso di malfunzionamento
del disco! Si scoprano gli errori
dell'amministratore di sistema adesso, non
non durante una vera crisi!
Sperimentate!
(noi abbiamo tolto corrente durante l'attività
del disco, poco ortodosso ma fa imparare molto).</LI>
<LI>effettuate una successione di mount/copy/unmount/rename/reboot
per muovere <CODE>/var</CODE> su <CODE>/dev/md1</CODE>.
Fatelo attentamente, non è pericoloso. </LI>
<LI>godetevi il tutto!</LI>
</UL>
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Quale è la differenza tra i comandi <CODE>mdadd</CODE>, <CODE>mdrun</CODE>,
<I>etc.</I> e quelli <CODE>raidadd</CODE>, <CODE>raidrun</CODE>?
<BLOCKQUOTE>
<B>R</B>:
I nomi dei tool sono stati cambiati dalla versione 0.5 del
pacchetto raidtools. La convenzione che voleva che i comandi
iniziassero per <CODE>md</CODE> era usata nella versione 0.43
e precedenti, mentre quella nuova che fa iniziare i comandi
per <CODE>raid</CODE> viene usata nella versione 0.5 e successive.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Vorrei utilizzare RAID-Linear/RAID-0 presente nel kernel
2.0.34. Vorrei non applicare la patch raid, poiché non sono
richieste per RAID-0/Linear. Dove posso procurarmi i tool
RAID per gestire il sistema?
<BLOCKQUOTE>
<B>R</B>:
Questa è una bella domanda, poiché i più nuovi
tool raid abbisognano che le patch RAID-1,4,5 siano
state applicate al kernel per compilarsi. Non conosco versioni
binarie, precompilate dei tool raid disponibili in questo
momento. Comunque sia, esperimenti hanno dimostrato
che i file binari dei tool raid, compilati su un kernel 2.1.100,
sembrano funzionare abbastanza bene nella creazione
di una partizione RAID-0/linear sotto 2.0.34. Un'anima
impavida me li ha chiesti ed io ho <B>temporaneamente</B>
reso disponibili i binari di mdadd, mdcreate, ecc, su
http://linas.org/linux/Software-RAID/
Avrete bisogno delle pagine di manuale, ecc. che si trovano
nel pacchetto standard dei raid-tools.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Posso mettere in strip/mirror la partizione di root (<CODE>/</CODE>)?
Perché non posso far partire Linux direttamente dai dischi <CODE>md</CODE>?
<BLOCKQUOTE>
<B>R</B>:
Sia LILO che Loadlin hanno bisogno di una partizione che non sia
in strip/mirror per potervi leggere l'immagine del kernel.
Se volete mettere in strip/mirror la partizione di root (<CODE>/</CODE>),
avrete bisogno di creare una partizione che non sia in strip/mirror
dove poter mettere il kernel. Tipicamente questa partizione viene
chiamata <CODE>/boot</CODE>. Fatto questo si può quindi usare o il
supporto per il ramdisk iniziale (initrd) o le patch di Harald Hoyer
<
<A HREF="mailto:HarryH@Royal.Net">HarryH@Royal.Net</A>>
che consentono ad una partizione in strip/mirror di essere usata
come root. (Adesso queste patch sono una parte standard dei recenti
kernel 2.1.x)
<P>Si possono usare approcci diversi.
Uno è documentato dettagliatamente nel
Bootable RAID mini-HOWTO:
<A HREF="ftp://ftp.bizsystems.com/pub/raid/bootable-raid">ftp://ftp.bizsystems.com/pub/raid/bootable-raid</A>.
<P>
<P>In alternativa, si può usare <CODE>mkinitrd</CODE> per costruire
un'immagine per il ramdisk, vedere di seguito.
<P>
<P>Edward Welbon
<
<A HREF="mailto:welbon@bga.com">welbon@bga.com</A>>
ha scritto:
<UL>
<LI>... tutto quello che serve è uno script che gestisca il setup
di boot.
Per montare un file system <CODE>md</CODE> come root,
la cosa principale da fare è costruire un'immagine iniziale
del file system che abbia i moduli e i tool md necessari per
far partire <CODE>md</CODE>. Io ho un semplice script che fa
tutto ciò.</LI>
</UL>
<UL>
<LI>Come supporto per il boot utilizzo un piccolo ed <B>economico</B>
disco SCSI (170MB lo ho preso usato per $20).
Il disco è collegato ad un AHA1452, ma avrebbe potuto essere
un disco IDE a buon prezzo sull'interfaccia nativa IDE.
Non c'è bisogno che sia un disco molto veloce poiché serve
solamente per il boot.</LI>
</UL>
<UL>
<LI>Questo disco contiene un piccolo file system dove trova posto il
kernel e l'immagine del file system per <CODE>initrd</CODE>.
L'immagine iniziale del file system contiene abbastanza roba
da permettermi di caricare il modulo driver per il dispositivo
raid SCSI e poter accedere alla partizione che diverrà root.
Poi eseguo un
<BLOCKQUOTE><CODE>
<PRE>
echo 0x900 > /proc/sys/kernel/real-root-dev
</PRE>
</CODE></BLOCKQUOTE>
(<CODE>0x900</CODE> è per <CODE>/dev/md0</CODE>)
e esco da <CODE>linuxrc</CODE>.
Il boot procede normalmente da qui in poi. </LI>
</UL>
<UL>
<LI>Ho compilato molti driver come moduli eccetto quello per
l'AHA1452 che serve per il file system <CODE>initrd</CODE>.
Il kernel che uso è così molto piccolo. Il metodo è
perfettamente affidabile, lo sto usando sin da prima
della versione 2.1.26 e non ho mai avuto un problema
che non sia riuscito a risolvere facilmente. Il file system
è addirittura sopravvissuto a diversi crash dei kernel
2.1.4[45] senza reali difficoltà.</LI>
</UL>
<UL>
<LI>Una volta avevo partizionato i dischi raid in maniera tale che
i cilindri iniziali del primo disco raid contenevano il kernel
e i cilindri iniziali del secondo disco raid contenevano
l'immagine iniziale del file system, adesso invece ho
messo la swap nei primi cilindri dei dischi raid poiché
questi sono i più veloci (perché sprecarli nel boot?).</LI>
</UL>
<UL>
<LI>La cosa bella dell'avere un dispositivo che costa poco dedicato
al boot è che è facile effettuarne il boot e che risulta utile
come disco di recupero se necessario. Se siete interessati,
potete dare un'occhiata allo script che genera l'immagine
iniziale per il ram disk e che quindi fa partire <CODE>LILO</CODE>.
<BLOCKQUOTE><CODE>
<A HREF="http://www.realtime.net/~welbon/initrd.md.tar.gz">http://www.realtime.net/~welbon/initrd.md.tar.gz</A></CODE></BLOCKQUOTE>
Per adesso è abbastanza per fare quello che serve.
Non è specificamente bello e potrebbe sicuramente costruire
un'immagine del file system molto più piccola per il ram disk
iniziale. Dovrebbe essere facile renderlo più efficiente.
Ma del resto usa <CODE>LILO</CODE> così com'è.
Se gli apportate dei miglioramenti vi prego di mandarmene una
copia. 8-)</LI>
</UL>
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Ho sentito dire che si può usare il mirroring sullo striping RAID.
È vero? Posso usare il mirroring sul dispositivo di loopback?
<BLOCKQUOTE>
<B>R</B>:
Si, ma non il contrario. Si può mettere una striscia su più
dischi e poi effettuarne il mirroring. Comunque sia lo striping
non può essere messo al di sopra del mirroring.
<P>Per darne una breve spiegazione tecnica si può dire che le
personality linear e stripe usano la routine <CODE>ll_rw_blk</CODE>
per gli accessi. La routine <CODE>ll_rw_blk</CODE> mappa dispositivi
di dischi e settori, non blocchi. I dispositivi a blocchi possono
essere stratificati uno sull'altro; ma i dispositivi che effettuano
un accesso al disco diretto, a basso livello, come fa <CODE>ll_rw_blk</CODE>
non possono essere sovrapposti.
<P>
<P>In questo momento (Novembre 1997) RAID non può funzionare sui
dispositivi di loopback, anche se questo dovrebbe essere possibile
a breve.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Ho due piccoli dischi e tre dischi più grandi. Posso concatenare i
due dischi piccoli con RAID-0 e quindi creare una partizione RAID-5
con questi e quelli più grandi?
<BLOCKQUOTE>
<B>R</B>:
In questo momento (Novembre 1997), non si può creare una
partizione RAID-5 in questa maniera. Si può farlo solo con
RAID-1 al di sopra della concatenazione dei drive.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Quale è la differenza tra RAID-1 e RAID-5 per una configurazione
che prevede due dischi (cioè la differenza tra una serie di due
dischi RAID-1 e una serie di due dischi RAID-5)?
<BLOCKQUOTE>
<B>R</B>:
Non c'è differenza nella capacità di immagazzinamento. Non si
possono aggiungere dischi a nessuno dei due sottosistemi per
aumentarne la capacità (vedi la domanda qui di seguito per i
dettagli).
<P>RAID-1 offre un vantaggio nella prestazione in lettura: il driver
RAID-1 usa la tecnologia distributed-read (lettura distribuita. ndt)
per leggere contemporaneamente due settori, uno da ogni disco,
raddoppiando la performance in lettura.
<P>Il driver RAID-5, anche se fortemente ottimizzato, attualmente
(Settembre 1997) non considera il fatto che il disco di parità
è una copia del disco dati. Quindi le letture avvengono in
maniera seriale.
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Come posso proteggermi dal malfunzionamento di due dischi?
<BLOCKQUOTE>
<B>A</B>:
Qualcuno degli algoritmi RAID protegge da un malfunzionamento
multiplo dei dischi, ma nessuno di questi algoritmi è attualmente
implementato da Linux. Detto ciò il Software RAID per Linux può
essere utilizzato per proteggersi da un malfunzionamento di
più dischi stratificando serie su serie di dischi. Per esempio,
nove dischi possono essere utilizzati per creare tre serie raid-5.
Quindi queste tre serie possono a loro volta essere legate assieme
in una singola serie di dischi RAID-5. In effetti questo tipo di
configurazione arriva a proteggere da un malfunzionamento di tre
dischi. Va notato il fatto che una grande quantità di spazio
disco va ''persa'' per la ridondanza delle informazioni.
<BLOCKQUOTE><CODE>
<PRE>
Per una serie di NxN dischi raid-5
N=3, 5 dischi su 9 sono usati per la parità (=55%)
N=4, 7 dischi su 16
N=5, 9 dischi su 25
...
N=9, 17 dischi su 81 (=~20%)
</PRE>
</CODE></BLOCKQUOTE>
In generale, una serie di MxN dischi userà MxN-1 dischi per la
parità. Lo spazio "perso" è minimo quando M=N.
<P>Un'altra alternativa è quella di creare una serie RAID-1
con tre dischi. Va notato il fatto che poiché tutti e tre i
dischi contengono dati identici, 2/3 dello spazio vanno
``sprecati''.
<P>
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Mi piacerebbe capire come è possibile che ci sia un programma tipo
<CODE>fsck</CODE>: se la partizione non è stata smontata in maniera
ortodossa, <CODE>fsck</CODE> interviene e riaggiusta il filesystem da solo
in più del 90% dei casi. Poiché la macchina è capace di
porsi rimedio da sola con <CODE>ckraid --fix</CODE>, perché non
farlo diventare automatico?
<BLOCKQUOTE>
<B>R</B>:
Si può ottenere ciò aggiungendo linee come le seguenti a
<CODE>/etc/rc.d/rc.sysinit</CODE>:
<PRE>
mdadd /dev/md0 /dev/hda1 /dev/hdc1 || {
ckraid --fix /etc/raid.usr.conf
mdadd /dev/md0 /dev/hda1 /dev/hdc1
}
</PRE>
o
<PRE>
mdrun -p1 /dev/md0
if [ $? -gt 0 ] ; then
ckraid --fix /etc/raid1.conf
mdrun -p1 /dev/md0
fi
</PRE>
Prima di presentare uno script più completo e affidabile,
rivediamo la teoria delle operazioni.
Gadi Oxman ha scritto:
In uno shutdown sporco, Linux può rimanere in uno degli stati
seguenti:
<UL>
<LI>Il dischi RAID erano stati aggiornati con i dati contenuti
nella memoria cache a loro destinata quando è avvenuto
lo shutdown; non sono andati persi dati.
</LI>
<LI>La memoria cache dei dischi RAID conteneva informazioni
non scritte sui dischi quando è avvenuto il blocco del
sistema; questo ha portato ad un filesystem danneggiato e
potenzialmente alla perdita di dati.
Quest'ultimo stato può essere ulteriormente suddiviso in
altri due stati:
<UL>
<LI>Linux era in fase di scrittura dati quando si è avuto
lo shutdown.</LI>
<LI>Linux non era in fase di scrittura dati quando si è
verificato il blocco.</LI>
</UL>
</LI>
</UL>
Supponiamo che stavamo usando una serie di dischi RAID-1. Nel caso
(2a) potrebbe accadere che, prima del blocco, un piccolo numero di
blocchi dati sia stato scritto con successo su solo alcuni dei
dischi di mirror e al prossimo boot i mirror non conterranno più`
gli stessi dati.
Se si ignorassero le differenze dei mirror, il codice di
bilanciamento della lettura dei raidtools-0.36.3 potrebbe scegliere
di leggere i suddetti dati da uno qualsiasi dei dischi di mirror,
cosa che porterebbe ad un comportamento incoerente (per esempio,
l`output di <CODE>e2fsck -n /dev/md0</CODE> potrebbe essere differente
di volta in volta).
<P>Poiché RAID non protegge dagli shutdown sporchi, usualmente non
c`e` un modo ''sicuramente corretto'' di correggere le differenze
nei dischi di mirror e il danneggiamento del filesystem.
<P>Per esempio il comportamento predefinito di <CODE>ckraid --fix</CODE>
sarà quello di scegliere il primo disco di mirror operativo e
aggiornare gli altri dischi di mirror con il suo contenuto.
Tuttavia, a seconda della situazione dei dischi al momento del
blocco, i dati negli altri dischi di mirror potrebbero essere
più recenti e si potrebbe scegliere di copiare i dati da quei
dischi o forse di usare un metodo differente per riparare le cose.
<P>Lo script che segue definisce una delle più robuste sequenze di
boot. In particolare si cautela dalle lunghe ripetizioni
dell`esecuzione di <CODE>ckraid</CODE> quando si ha a che fare
con dischi, controller o driver dei controller che non cooperano.
Lo si modifichi in modo da adeguarlo alla propria configurazione,
e lo si copi su <CODE>rc.raid.init</CODE>. Quindi si esegua <CODE>rc.raid.init</CODE>
dopo che la partizione di root è stata controllata da fsck e
montata in lettura/scrittura ma prima che le rimanenti partizioni
siano controllate da fsck. Assicurarsi che la directory attuale
sia nel percorso di ricerca.
<PRE>
mdadd /dev/md0 /dev/hda1 /dev/hdc1 || {
rm -f /fastboot # forza l`esecuzione di fsck
ckraid --fix /etc/raid.usr.conf
mdadd /dev/md0 /dev/hda1 /dev/hdc1
}
# se il sistema si bloccasse più avanti durante questo processo di boot
# vorremmo che almeno questo dispositivo md non ne risentisse.
/sbin/mdstop /dev/md0
mdadd /dev/md1 /dev/hda2 /dev/hdc2 || {
rm -f /fastboot # forza l`esecuzione di fsck
ckraid --fix /etc/raid.home.conf
mdadd /dev/md1 /dev/hda2 /dev/hdc2
}
# se il sistema si bloccasse più avanti durante questo processo di boot
# vorremmo che almeno questo dispositivo md non ne risentisse.
/sbin/mdstop /dev/md1
mdadd /dev/md0 /dev/hda1 /dev/hdc1
mdrun -p1 /dev/md0
if [ $? -gt 0 ] ; then
rm -f /fastboot # forza l`esecuzione di fsck
ckraid --fix /etc/raid.usr.conf
mdrun -p1 /dev/md0
fi
# se il sistema si bloccasse più avanti durante questo processo di boot
# vorremmo che almeno questo dispositivo md non ne risentisse.
/sbin/mdstop /dev/md0
mdadd /dev/md1 /dev/hda2 /dev/hdc2
mdrun -p1 /dev/md1
if [ $? -gt 0 ] ; then
rm -f /fastboot # forza l`esecuzione di fsck
ckraid --fix /etc/raid.home.conf
mdrun -p1 /dev/md1
fi
# se il sistema si bloccasse più avanti durante questo processo di boot
# vorremmo che almeno questo dispositivo md non ne risentisse.
/sbin/mdstop /dev/md1
# OK, adesso con i soli comandi md. Se ci fossero stati errori
# i controlli precedenti dovrebbero aver rimesso tutto a posto.
/sbin/mdadd /dev/md0 /dev/hda1 /dev/hdc1
/sbin/mdrun -p1 /dev/md0
/sbin/mdadd /dev/md12 /dev/hda2 /dev/hdc2
/sbin/mdrun -p1 /dev/md1
</PRE>
In aggiunta a questo si dovrà creare un file <CODE>rc.raid.halt</CODE>
che dovrebbe apparire come questo:
<PRE>
/sbin/mdstop /dev/md0
/sbin/mdstop /dev/md1
</PRE>
Assicuratevi di aver modificato sia <CODE>rc.sysinit</CODE> che
<CODE>init.d/halt</CODE> per far eseguire questa procedura da
qualsiasi parte il filesystem venga smontato prima di un halt/reboot.
(Si noti che <CODE>rc.sysinit</CODE> smonta ed effettua un reboot se
<CODE>fsck</CODE> termina l`esecuzione con un errore.)
<P>
</BLOCKQUOTE>
</LI>
<LI><B>D</B>:
Posso configurare metà di un mirror RAID-1 con il solo disco che ho
adesso e poi dopo aggiungervi semplicemente un altro disco?
<BLOCKQUOTE>
<B>R</B>:
Con gli strumenti di adesso no, almeno non in maniera semplice.
In particolare non si può solamente copiare il contenuto di un
disco su un altro e poi appaiarli. Questo a causa del fatto che
i driver RAID usano un poco di spazio alla fine della
partizione per memorizzare i superblock. Questo diminuisce
leggermente lo spazio disponibile per il filesystem; ma se si
provasse a forzare una partizione RAID-1 su una partizione con
un filesystem preesistente, i superblock sovrascriverebbero una
parte del filesystem confondendo i dati. Poiché il filesystem
ext2fs distribuisce i file in maniera casuale su una partizione
(per evitarne la frammentazione), con grossa probabilità
qualche file risiederà alla fine della partizione anche se il
disco non è pieno.
<P>Se siete abili, suppongo che possiate calcolarvi quanto spazio
il superblock RAID occuperà e quindi rendere il filesystem
leggermente più piccolo, in modo da lasciare lo spazio di cui
la memorizzazione del superblock RAID avrà bisogno in seguito.
Ma, se siete così abili, sarete quindi abbastanza bravi da
modificare i tool in modo tale che lo facciano automaticamente
(i tool non sono terribilmente complessi).
<P>
<P><B>Nota:</B> il lettore attento avrà pensato che il trucco
seguente potrebbe funzionare; non l'ho provato né verificato:
Eseguite <CODE>mkraid</CODE> con <CODE>/dev/null</CODE> come uno dei
dispositivi. Quindi eseguite <CODE>mdadd -r</CODE> sul solo vero disco
(non eseguite mdadd <CODE>/dev/null</CODE>). Il comando <CODE>mkraid</CODE>
dovrebbe aver configurato con successo il sistema raid, e il
comando mdadd serve solo a forzare il funzionamento del sistema
in modalità "degradata" (in inglese "degraded mode". ndt),
come se uno dei due dischi fosse rotto.
</BLOCKQUOTE>
</LI>
</OL>
<HR>
<A HREF="Software-RAID-0.4x-HOWTO-4.html">Avanti</A>
<A HREF="Software-RAID-0.4x-HOWTO-2.html">Indietro</A>
<A HREF="Software-RAID-0.4x-HOWTO.html#toc3">Indice</A>
</BODY>
</HTML>
