<!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>