Questo è quello di cui avete bisogno per qualunque livello RAID:
Tutto questo software può essere trovato presso ftp://ftp.fi.kernel.org/pub/linux I RAID tool e le patch sono nella subdirectory daemons/raid/alpha
subdirectory. I kernel si possono trovare nella subdirectory kernel.
Applicate la patch al kernel, configuratelo per includere il supporto al livello RAID che volete usare. Compilatelo ed installatelo.
Poi, decompattate, configurate, compilate ed installate i RAID tool.
Ok, fatto. Se fate un reboot ora, dovreste avere un file di nome /proc/mdstat. Ricordate, questo file è vostro amico. Guardate cosa contiene facendo un cat /proc/mdstat. Esso dovrebbe dirvi che avete la corretta RAID personality (modalità RAID) registrata e che nessun dispositivo RAID è al momento attivo.
Create ora le partizioni che volete includere nel RAID array.
Da ora, analizziamo specificamente ogni modalità in maniera separata.
Ok, avete a disposizione due o più partizioni che non hanno necessariamente le stesse dimensioni (ma naturalmente potrebbero averle), volete a questo punto "appenderle" una all'altra.
Preparate il file /etc/raidtab per dare una descrizione del vostro sistema. Io ho preparato un raidtab per due dischi in linear mode, il file si presenta nel seguente modo:
raiddev /dev/md0
raid-level linear
nr-raid-disks 2
chunk-size 32
persistent-superblock 1
device /dev/sdb6
raid-disk 0
device /dev/sdc5
raid-disk 1
Gli spare-disk non sono supportati in questa modalità. Se un disco si guasta, l'array si blocca con esso. Non ci sono informazioni da mettere su uno spare disk.
Probabilmente vi chiederete come mai abbia specificato una "chunk-size" qui, quando il linear-mode non fa altro che "appendere" i dischi in un grande array senza alcun parallelismo. Bene, avete perfettamente ragione, è strano. Mettete una qualche chunk size e non preoccupatevene ulteriormente.
Ok, creiamo l'array. Date il comando
mkraid /dev/md0
Questo inizializzerà il vostro array, scriverà i persistent superblock e farà partire l'array.
Date un'occhiata a /proc/mdstat. Dovreste vedere che l'array sta lavorando.
Ora, potete creare un filesystem, come fareste su qualunque altro dispositivo, montarlo, includerlo in fstab e così via.
Avete due o più dischi approssimativamente della stessa dimensione e volete combinare le loro capacità di "memorizzazione" e combinare anche le loro prestazioni facendoci degli accessi in parallelo.
Preparate il file/etc/raidtab per descrivere la vostra configurazione. Un file raidtab di esempio appare così:
raiddev /dev/md0
raid-level 0
nr-raid-disks 2
persistent-superblock 1
chunk-size 4
device /dev/sdb6
raid-disk 0
device /dev/sdc5
raid-disk 1
Come nel linear-mode, gli spare disk non sono supportati. Il RAID-0 non ha ridondanza, così quando un disco si guasta, l'array lo segue.
Ancora una volta date il comando
mkraid /dev/md0per inizializzare l'array. Questo dovrebbe inizializzare i superblocchi e far partire il dispositivo RAID. Date un occhiata a
/proc/mdstat per vedere cosa sta succedendo. Dovreste vedere che il vostro dispositivo ora sta lavorando.
/dev/md0 ora è pronto per essere formattato, montato, usato e abusato.
Avete due o più dischi approssimativamente delle stesse dimensioni e volete che ognuno sia l'immagine (mirror) esatta dell'altro. Eventualmente potete avere più dischi, che volete tenere come spare-disk, che automaticamente diverranno parte dell'array se uno dei dischi attivi si guasta.
Preparate il file /etc/raidtab nel seguente modo:
raiddev /dev/md0
raid-level 1
nr-raid-disks 2
nr-spare-disks 0
chunk-size 4
persistent-superblock 1
device /dev/sdb6
raid-disk 0
device /dev/sdc5
raid-disk 1
Se avete spare disks, potete aggiungerli alla fine della specifica del dispositivo nel modo seguente
device /dev/sdd5
spare-disk 0
Ricordate di dichiarare la voce nr-spare-disks in modo corrispondente.
Ok, abbiamo preparato tutto per far partire il RAID. L'immagine (mirror) deve essere costruita, cioè il contenuto (che al momento non è importante, in quanto il device deve ancora essere formattato) dei due dischi deve essere sincronizzato.
Date il comando
mkraid /dev/md0per dare il via all'inizializzazione del mirror.
Controllate il file /proc/mdstat file. Dovrebbe dirvi che il dispositivo /dev/md0 è partito, che l'immagine (mirror) è in corso di ricostruzione e un ETA dello stato della ricostruzione.
Dovrebbe dirvi che il dispositivo /dev/md0 è partito, che l'immagine (mirror) è in corso di ricostruzione e un ETA dello stato della ricostruzione.
La ricostruzione è fatta utilizzando la larghezza di banda dell'I/O inutilizzata. Così, il sistema dovrebbe ancora essere piuttosto pronto a rispondere, sebbene gli hard disk led dovrebbero lampeggiare allegramente.
Provate a formattare il dispositivo, mentre la ricostruzione è in corso. Funzionerà. Potete anche montarlo ed usarlo mentre la ricostruzione è in corso. Naturalmente, se il disco sbagliato si rompe mentre la ricostruzione è in corso, non avete speranze.
Notate bene! Non ho mai fatto un test di un sistema del genere. Il setup seguente è una mia fondata congettura, ma nessuna sua parte è mai stata fatta girarare.
Avete tre o più dischi approssimativamente della stessa dimensione, uno dei dischi è significativamente più veloce degli altri e voi volete combinarli in un dispositivo più grande, mantenendo ancora delle informazioni di ridondanza. Eventualmente avete un certo numero di dischi che vorreste usare come spare-disk.
Preparate il file /etc/raidtab nel modo seguente:
raiddev /dev/md0
raid-level 4
nr-raid-disks 4
nr-spare-disks 0
persistent-superblock 1
chunk-size 32
device /dev/sdb1
raid-disk 0
device /dev/sdc1
raid-disk 1
device /dev/sdd1
raid-disk 2
device /dev/sde1
raid-disk 3
Se disponessimo di spare disk, essi devono essere inseriti in un modo simile, seguendo le specifiche dei dischi RAID;
device /dev/sdf1
spare-disk 0
come al solito.
Il vostro array può essere inizializzato con il comando
mkraid /dev/md0come al solito.
Dovreste dare un'occhiata alla sezione sulle opzioni speciali per mke2fs prima di formattare il dispositivo.
Avete tre o più dischi approssimativamente della stessa dimensione che volete combinare in un dispositivo più grande, mantenendo ancora un certo grado di ridondanza per la sicurezza dei dati. Eventualmente potete avere un certo numero di dischi da usare com spare disk, che non fanno parte dell'array fino a che un altro disco si guasta.
Se usate N dischi di cui il più piccolo ha dimensione S, la dimensione dell'intero array sarà (N-1)*S. Questo spazio è ``perso'' per le informazioni di parità (ridondanza). Quindi, se uno dei dischi si guasta i dati saranno ancora intatti. Ma se due dischi si guastano, tutti i dati andranno persi.
Preparate il file /etc/raidtab nel seguente modo:
raiddev /dev/md0
raid-level 5
nr-raid-disks 7
nr-spare-disks 0
persistent-superblock 1
parity-algorithm left-symmetric
chunk-size 32
device /dev/sda3
raid-disk 0
device /dev/sdb1
raid-disk 1
device /dev/sdc1
raid-disk 2
device /dev/sdd1
raid-disk 3
device /dev/sde1
raid-disk 4
device /dev/sdf1
raid-disk 5
device /dev/sdg1
raid-disk 6
Se disponete di spare disk, essi dovrebbero essere inseriti in una maniera simile, seguendo le specifiche dei dischi raid;
device /dev/sdh1
spare-disk 0
e così via.
Una chunk size di 32 KB è un buon valore di default per la maggior parte dei filesystem di uso generale. L'array su cui la precedente raitab viene usata, è un dispositivo da 7 dischi da 6 GB = 36 GB (ricordando che (n-1)*s = (7-1)*6 = 36). Su di esso è costruito un ext2 filesystem con una dimensione del blocco da 4 KB. Potreste aumentare sia la chunk size dell'array sia la dimensione del blocco del filesystem se il vostro filesystem è o molto più grande o è costituito da file molto grandi.
Ok, abbiamo parlato abbastanza. Avete preparato la raidtab, andiamo a vedere se funziona. Date il comando
mkraid /dev/md0e state a vedere cosa succede. Se tutto è andato a buon fine i vostri dischi dovrebbero iniziare a lavorare come matti, iniziando la ricostruzione dell'array. Date un occhiata a
/proc/mdstat per vedere cosa sta succedendo.
Se la creazione del dispositivo è avvenuta con successo, il processo di ricostruzione è iniziato a questo punto. Il contenuto del vostro array non è consistente finché questa fase di ricostruzione non è terminata. Comunque, l'array è completamente funzionanate (eccetto che per la gestione dei guasti naturalmente) e quindi potete formattarlo anche durante la fase di ricostruzione.
Date un occhiata al paragrafo sulle opzioni speciali di mke2fs prima di formattare l'array.
Date un occhiata al paragrafo sulle opzioni speciali di mke2fs prima di formattare l'array.
Ok, ora che avete il RAID device funzionante, potete sempre arrestarlo e farlo ripartire usando i comandi
raidstop /dev/md0o
raidstart /dev/md0
Invece di mettere questi comandi nei file init e fare il reboot un fantastilione di volte per arrivare ad un sistema funzionante, continuate a leggere e capirete come poter far funzionare l'autorilevamento (autodetection).
`Tanto tempo fa...'' (TM), i raidtools avrebbero letto il vostro file /etc/raidtab e poi avrebbero inizializzato l'array. Comunque, questo avrebbe richiesto che il filesystem su cui risiedeva /etc/raidtab fosse montato. Questo risulta essere sfavorevole se avete intenzione di fare il boot da raid..
Inoltre il vecchio approccio portava a delle complicazioni quando si montavano i filesystem sui dispositivi RAID. Essi non potevano essere messi nel file /etc/fstab come al solito, ma avrebbero dovuto essere montati negli init script.
I persistent superblock risolvono questi problemi. Quando un array è inizializzato con l'opzione persistent-superblock nel file /etc/raidtab uno speciale superblock viene scritto all'inizio di tutti i dischi che compongono l'array. Questo permette al kernel di leggere la configurazione dei dispositivi RAID direttamente dai dischi che ne fanno parte, invece di ottenerla da qualche file di configurazione che potrebbe non essere disponibile in qualche momento.
Dovreste comunque mantenere un file /etc/raidtab file, consistente, poiché potreste aver bisogno di questo file per le successive ricostruzioni dell'array.
Il persistent superblock è obbligatorio se volete l'auto rilevamento (autodetection) dei vostri dispositivi RAID al boot del sistema. Tutto ciò è descritto nel paragrafo Autorilevamento (autodetection).
La chunk-size necessita di una spiegazione. Voi non potete mai scrivere completamente in parallelo su una batteria di dischi. Se avete due dischi e volete scriverci un byte, dovreste scrivere quattro bit su ogni disco, effettivamente, ogni bit pari andrebbe sul disco 0 e gli altri sul disco 1. L'hardware non supporta tutto questo. Invece, noi scegliamo alcune chunk size, che definiamo come come la più piccola massa ``atomica'' di dati che possa essere scritta su un dispositivo. Una scrittura di 16KB con una chunk-size di 4KB, farà si che il primo e il terzo chunk da 4KB siano scritti sul primo disco ed il secondo e il quarto chunk siano scritti sul secondo disco, nel caso di un RAID-0 con due dischi. Quindi, per scritture di grosse quantità di dati, si può notare un miglioramento dall'usare dei chunk piuttosto grandi, mentre gli array che contengono principalmente piccoli files beneficieranno di una piccola dimensione dei chunk.
Le dimensioni dei chunk devono essere specificate per tutti i livelli RAID, incluso il linear-mode. Comunque la chunk-size non fa alcuna differenza per il linear-mode.
Per avere prestazioni ottimali, dovreste sperimentare con i valori, così come con la dimensione del blocco del filesystem che costruite sull'array.
L'argomento dell'opzione chunk-size in
/etc/raidtab
I dati sono scritti ``quasi'' in parallelo nei dischi dell'array. Effettivamente, i blocchi di dimensione chunk-size sono scritti in ogni disco serialmente.
Se specificate una chunk-size di 4 KB e scrivete 16 KB su un array di tre dischi, il sistema RAID scriverà 4 KB nei dischi 0, 1, 2, in parallelo, e poi i rimanenti 4 KB sul disco 0.
Una chunk-size di 32 KB è un punto di partenza ragionevole per la maggior parte degli array. Ma il valore ottimale dipende molto dal numero dei dischi costituenti l'array, dal contenuto del filesystem che ci viene messo sopra e da molti altri fattori. Sperimentate, per ottenere le migliori prestazioni.
Per le scritture la chunk-size non ha influenza sull'array, in quanto i dati devono essere scritti su tutti i dischi dell'array. Per le letture comunque, la chunk-size specifica quanti dati leggere serialmente dai dischi facenti parte dell'array. Poiché tutti i dischi attivi nell'array contengono la stessa informazione, le letture possono essere fatte in parallelo in modo simile al RAID-0.
Quando una scrittura è fatta su un array RAID-4, le informazioni dei parità devono sempre essere aggiornate sul disco di parità. La chunk-size è la dimensione del blocco di parità. Se un byte viene scritto su un array RAID-4, allora dei blocchi di dimensione chunk-size saranno letti dagli N-1 dischi, verrà calcolata l'informazione di parità e i blocchi di dimensione chunk-size saranno scritti nel disco di parità.
La chunk-size influenza le prestazioni in lettura nello stesso modo che nel RAID-0, visto che le letture da un array RAID-4 vengono effettuate nello stesso modo.
Sugli array RAID-5 la chunk-size ha esattamente lo stesso significato che nel RAID-4.
Una chunk-size ragionevole per un array RAID-5 è 128 KB, come sempre, potete sperimentare con essa.
Date anche un occhiata al paragrafo sulle opzioni speciali di mke2fs. Questo influenza le performance di un array RAID-5.
Esiste un'opzione speciale per formattare un dispositivo RAID-4 o RAID-5 con mke2fs. L'opzione -R stride=nn permetterà a mke2fs di piazzare meglio delle strutture dati specifiche dell'ext2 in modo intelligente sul dispositivo RAID.
Se la chunk-size è di 32 KB, ciò significa che blocchi da 32 KB di dati consecutivi saranno presenti su un disco. Se volessimo costruire un ext2 filesystem con una dimensione del blocco da 4 KB, si capisce che avremmo otto blocchi del filesystem per ogni chunk dell'array. Noi possiamo passare questa informazione all'utility mke2fs al momento di creare il filesystem:
mke2fs -b 4096 -R stride=8 /dev/md0
Le prestazioni dei RAID-{4,5} sono fortemente influenzate da questa opzione. Non sono sicuro di come l'opzione stride influenzi gli altri livelli RAID. Se qualcuno avesse maggiori informazioni su questo, per favore me le faccia avere.
La dimensione del blocco dell'ext2fs influenza fortemente le prestazioni del filesystem. Dovreste usare sempre la dimensione del blocco da 4 KB su ogni filesystem più grande di qualche centinaia di megabyte, a meno che non stiate lavorando con un gran numero di piccoli file.
L'autorilevamento permette ai dispositivi RAID di essere automaticamente riconosciuti dal kernel al boot del sistema, subito dopo che il rilevamento solito delle partizioni è stato eseguito.
Tutto ciò richiede diverse cose:
NOTA: Siate certi che che il vostro RAID NON stia lavorando prima di cambiare il tipo della partizione. Usate raidstop /dev/md0 per arrestare il dispositivo.
Se preparate tutto in modo congruente ai precedenti punti 1, 2 e 3, l'autorilevamento dovrebbe avvenire. Provate a fare un reboot. Quando il sistema riparte, fate un cat di /proc/mdstatche dovrebbe dirvi che il vostro dispositivo RAID sta funzionando
.
Durante il boot, dovreste vedere dei messaggi simili a:
Oct 22 00:51:59 malthe kernel: SCSI device sdg: hdwr sector= 512 bytes. Sectors= 12657717 [6180 MB] [6.2 GB] Oct 22 00:51:59 malthe kernel: Partition check: Oct 22 00:51:59 malthe kernel: sda: sda1 sda2 sda3 sda4 Oct 22 00:51:59 malthe kernel: sdb: sdb1 sdb2 Oct 22 00:51:59 malthe kernel: sdc: sdc1 sdc2 Oct 22 00:51:59 malthe kernel: sdd: sdd1 sdd2 Oct 22 00:51:59 malthe kernel: sde: sde1 sde2 Oct 22 00:51:59 malthe kernel: sdf: sdf1 sdf2 Oct 22 00:51:59 malthe kernel: sdg: sdg1 sdg2 Oct 22 00:51:59 malthe kernel: autodetecting RAID arrays Oct 22 00:51:59 malthe kernel: (read) sdb1's sb offset: 6199872 Oct 22 00:51:59 malthe kernel: bind<sdb1,1> Oct 22 00:51:59 malthe kernel: (read) sdc1's sb offset: 6199872 Oct 22 00:51:59 malthe kernel: bind<sdc1,2> Oct 22 00:51:59 malthe kernel: (read) sdd1's sb offset: 6199872 Oct 22 00:51:59 malthe kernel: bind<sdd1,3> Oct 22 00:51:59 malthe kernel: (read) sde1's sb offset: 6199872 Oct 22 00:51:59 malthe kernel: bind<sde1,4> Oct 22 00:51:59 malthe kernel: (read) sdf1's sb offset: 6205376 Oct 22 00:51:59 malthe kernel: bind<sdf1,5> Oct 22 00:51:59 malthe kernel: (read) sdg1's sb offset: 6205376 Oct 22 00:51:59 malthe kernel: bind<sdg1,6> Oct 22 00:51:59 malthe kernel: autorunning md0 Oct 22 00:51:59 malthe kernel: running: <sdg1><sdf1><sde1><sdd1><sdc1><sdb1> Oct 22 00:51:59 malthe kernel: now! Oct 22 00:51:59 malthe kernel: md: md0: raid array is not clean -- starting background reconstructionQuesto è quello che si ottiene dall'autorilevamento di un array RAID-5 che non è stato arrestato in modo pulito (per esempio se si è avuto un blocco della macchina). La ricostruzione viene iniziata automaticamente. Montare questo dispositivo è perfettamente sicuro, poiché la ricostruzione è trasparente e tutti i dati sono consistenti (è solo l'informazione di parità che è inconsistente - ma non c'è nessuna necessità di essa finché un dispositivo non si guasta).
I dispositivi che vengono avviati automaticamente sono anche arrestati automaticamente quando si ferma la macchina (shutdown). Non vi curate degli init script. Usate solo i device /dev/md come ogni altro device /dev/sd o /dev/hd.
Si, è veramente così semplice.
Potreste voler dare un occhiata ai vostri init-script per cercare i comandi raidstart/raidstop. Essi si trovano di solito negli init script della RedHat. Sono utilizzati solo per il vecchio RAID e non servono a niente nel nuovo RAID con l'autorilevamento. Potete semplicemente rimuovere queste linee e tutto continuerà a funzionare bene.
Ci sono diversi modi per costruire un sistema che monti il suo root filesystem su un dispositivo RAID. Al momento solo l'installazione grafica di Linux RedHat 6.1 permette l'installazione diretta di un dispositivo RAID. E'comunque possibile realizzare la cosa.
L'ultima distribuzione ufficiale di lilo (Versione 21) non gestisce i dispositivi RAID e quindi il kernel non può essere caricato al boot dal dispositivo RAID. Se usate questa versione, il vostro /boot filesystem dovrà stare su un dispositivo non-RAID. Un modo per assicurarsi che che il sistema faccia il boot comunque, è quello di creare delle partizioni /boot uguali su tutti i dischi del vostro RAID, in questo modo il BIOS può sempre caricare i dati per esempio dal primo disco disponibile. Questo presume che non facciate il boot da un disco guasto nel vostro sistema..
Con la RedHat 6.1 una patch per lilo 21 è diventata disponibile, essa può gestire il /boot su un RAID-1. Notate che essa non funzionerà per qualunque altro livello, RAID-1 (mirroring) è il solo livello RAID supportato. Questa patch (lilo.raid1) può essere trovata presso dist/redhat-6.1/SRPMS/SRPMS/lilo-0.21-10.src.rpm su ogni RedHat mirror. La versione di lilo a cui viene applicata la patch accetterà la voce boot=/dev/md0 nel file lilo.conf e renderà ogni ogni disco immagine (mirror) pronto per il boot.
Un altro modo per assicurare che il sistema riesca sempre a fare il boot è di creare un floppy di boot dopo che tutto il sistema è stato costruito. Se il disco sul quale il filesystem /bootrisiede si blocca, è sempre possibile fare il boot da floppy.
Al fine di avere un sistema che faccia il boot su RAID, il root filesystem (/) deve essere montato su un dispositivo RAID. Due metodi per realizzare questo sono dati sotto. Visto che nessuna delle attuali distribuzioni (almeno di cui io sia a conoscenza) supporta l'installazione su un dispositivo RAID, questi metodi presumono che voi abbiate installato su una normale partizione e poi - quando l'installazione è finita - spostiate il contenuto del vostro root filesystem non-RAID sul nuovo dispositivo RAID.
Questo metodo presume che voi abbiate degli spare-disk, che non fanno parte del sistema RAID che state configurando, su cui possiate installare il sistema operativo.
mke2fs), e montatelo sotto /mnt/newrootcd / find . -xdev | cpio -pm /mnt/newroot
/mnt/newroot/etc/fstab per utilizzare il giusto dispositivo( il/dev/md? root device) per il root filesystem./boot filesystem, e montiamo invece il dispositivo di boot su /mnt/newroot/boot. Questo è necessario per far lavorare correttamente lilo nel prossimo punto./mnt/newroot/etc/lilo.conf per puntare al giusto dispositivo. Il dispositivo di boot deve ancora essere un normale disco (non un dispositivo RAID), ma il root device deve puntare al nuovo RAID. Quando l'avete fatto, date il comando
lilo -r /mnt/newroot, LILO dovrebbe essere eseguito senza errori.
Se fate tutto ciò con dischi IDE, siate sicuri di comunicare al BIOS che tutti i dischi sono di tipo "auto-detect", così che il BIOS permetterà alla vostra macchina di fare il boot, anche se un disco viene perso.
Questo metodo necessita che voi usiate una raidtools/patch che include la direttiva failed-disk. Questa sarà la tools/patch per tutti i kernel verione 2.2.10 e successive.
Voi potete usare questo metodo solo un RAID di livello 1 e superiore. L'idea è quella di installare il sistema su un disco che è, di proposito, marcato come guasto all'interno del RAID, allora copiate il sistema sul RAID che lavorerà in modalità "degraded" e finalmente farete usare al RAID il non più necessario ``install-disk'', saltando la vecchia installazione, ma facendo lavorare il RAID in modalità "non degraded".
failed-disk nel file raidtab. Non mettete il failed-disk come primo disco nel fileraidtab, questo comporterebbe dei problemi all'avvio del RAID. Create il RAID e costruite un filesystem su di esso.raidtab per includervi il failed-disk come unraid-disk. Ora, fate raidhotadd con il vostro disco al RAID.
Perché un kernel sia in grado di montare un root filesystem, il supporto per il dispositivo su cui il filesystem risiede deve essere presente nel kernel. Perciò, al fine di montare il root filesystem su un device RAID, il kernel deve avere il supporto RAID.
La maniera normale per essere certi che il kernel possa vedere il dispositivo RAID è semplicemente quella di compilare il kernel con tutto il supporto RAID necessario. Siate sicuri di aver compilato il supporto RAID nel kernel, e non come modulo caricabile. Il kernel non può caricare un modulo (dal root filesystem) finché il root filesystem non è montato.
Comunque, poiché RedHat-6.0 è distribuita con un kernel che ha il supporto per il nuovo RAID come modulo, qui verrà descritto come usare il kernel standard della RedHat-6.0, continuando a fare il boot del sistema da RAID.
Dovrete "istruire" LILO ad usare un RAM-disk per ottenere questo. Usate il comando mkinitrd per creare un ramdisk contenente tutti i moduli del kernel necessari a montare la partizione di root. Questo può essere fatto nel seguente modo:
mkinitrd --with=<module> <ramdisk name> <kernel>Per esempio:
mkinitrd --with=raid5 raid-ramdisk 2.2.5-22
Questo ci rende sicuri che il modulo RAID specificato sia presente al boot quando il kernel monterà il root device.
Non dovete mai MAI mai ripartizionare i dischi che fanno parte di un array attivo. Se dovete alterare la tabella delle partizioni su un disco che fa parte di un RAID, arrestate l'array e poi ripartizionate.
E' facile mettere troppi dischi su un bus. Un normale Fast-Wide SCSI bus può sopportare 10 MB/s, che è meno di quanto alcuni dischi possano fare oggi. Mettere sei di questi dischi sul bus non vi darà di certo il guadagno di prestazioni che vi aspettate.
Un maggior numero di controller SCSI vi daranno delle prestazioni migliori, se i bus SCSI sono quasi saturati da dischi collegati. Non vedrete un incremento di prestazioni dall'uso di due 2940 con due vecchi dischi SCSI rispetto a far lavorare i due dischi su un solo controller.
Se vi dimenticate dell'opzione persistent-superblock, il vostro array non ripartirà volentieri dopo che è stato arrestato. Ricreate allora l'array con l'opzione abilitata nel file raidtab.
Se un RAID-5 fallisce la ricostruzione dopo che un disco è stato rimosso e riinserito, questo potrebbe dipendere dall'ordine dei dispositivi nel file raidtab. Provate a spostare la prima coppia ``device ...'' / ``raid-disk ...'' in fondo alla descrizione dell'array nel file raitab.
La maggior parte degli ``error reports'' che trovate sulla linux-kernel list, sono di persone che in qualche modo hanno sbagliato ad usare la giusta patch raid con la corrispondente versione dei raidtools. Siate sicuri di utilizzare 0.90 RAID, e che state usando i raidtools per esso.