Page suivante - Page précédente - Table des matières

4. Configuration du RAID

4.1 Configuration générale

Voici ce que requièrent tous les niveaux de RAID  :

  • Un noyau, de préférence un 2.2.x ou le dernier 2.0.x. Si la branche 2.4.x est disponible quand vous lirez ces lignes, servez vous en.
  • Les patches RAID. Ils existent généralement pour les noyaux récents. Les noyaux 2.4.x ne nécessiteront pas de patch.
  • Les utilitaires RAID.
  • De la patience, des pizzas et des amph^H^H^H^H substances à la caféine.

Tous les logiciels se trouvent sur ftp://ftp.fi.kernel.org/pub/linux Les outils et les patches RAID sont dans le répertoire daemons/raid/alpha. Le noyau se trouve dans le répertoire kernel.

Patchez le noyau, configurez le de façon à inclure la gestion du RAID pour les niveaux qui vous intéressent. Compilez et installez.

Détarrez, configurez, compilez et installez les outils RAID.

Jusqu'ici, tout va bien. A présent, si vous redémarrez, vous devriez avoir un fichier appelé /proc/mdstat. N'oubliez jamais que ce fichier est votre allié. Examinez son contenu avec un cat /proc/mdstat. Il devrait vous confirmer que vous disposez du niveau (personality) RAID voulu et qu'aucun périphérique RAID n'est actif.

Créez les partitions que vous souhaitez inclure dans votre matrice RAID.

La suite des opérations dépend à présent du mode RAID.

4.2 Mode linéaire

On dispose à présent de deux partitions (ou plus) qui ne sont pas nécessairement de la même taille et que l'on va concaténer.

Editez le fichier /etc/raidtab de façon à correspondre à votre configuration. Pour deux disques en mode linéaire, voici un fichier type  :

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
On ne peut disposer de disques de secours. Si un disque tombe en panne, toute la matrice s'effondre. Il n'y a rien à stocker sur un disque de secours.

Vous vous demanderez peut-être pourquoi on précise un paramètre chunk-size quand le mode linéaire ne fait que concaténer les disques en un disque virtuel plus important sans y accéder en parallèle. Vous avez tout à fait raison. Mettez y une valeur quelconque et pensez à autre chose.

On crée la matrice  :

 mkraid /dev/md0

La commande initialise la matrice, écrit les superblocs persistants et active le périphérique.

Jetez un oeil à /proc/mdstat. Vous devriez y voir que la matrice fonctionne.

A présent créez un système de fichiers comme sur un périphérique quelconque, montez le, incluez le dans votre fstab etc...

4.3 RAID-0

On dispose de deux disques (ou davantage) de taille sensiblement égale dont on veut additionner les capacités de stockage tout en en améliorant les performances au moyen d'accès simultanés.

Editez le fichier /etc/raidtab de façon à correspondre à votre configuration. Voici un fichier type  :

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
Comme en mode linéaire, il n'y a pas de disque de secours. Le RAID-0 n'offre aucune redondance et la défaillance d'un disque signifie celle de la matrice entière.

On exécute  :

 mkraid /dev/md0
La commande initialise la matrice, écrit les superblocs persistants et active la matrice.

/dev/md0 est prêt à être formaté, monté et à subir les pires outrages.

4.4 RAID-1

On dispose de deux disques de taille sensiblement égale que l'on souhaite mettre en mirroir. On peut avoir des disques supplémentaires que l'on gardera en attente comme disques de secours et qui prendront automatiquement place dans la matrice si un disque actif tombe en panne.

Voici le fichier /etc/raidtab typique  :

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
Pour prendre en compte des disques de secours  :
 device          /dev/sdd5
 spare-disk      0
N'oubliez pas d'ajuster la variable nr-spare-disks en conséquence.

A présent, on peut initialiser la matrice RAID. Son contenu doit être construit et les contenus des deux disques (sans importance pour l'instant) synchronisés.

Exécutez  :

 mkraid /dev/md0
L'initialisation de la matrice démarrera.

Examinez le fichier /proc/mdstat. On doit y lire que /dev/md0 a été démarré, que le mirroir est en cours de reconstruction et y trouver une estimation de la durée de reconstruction.

La reconstruction a lieu durant les périodes d'inactivité au niveau des entrées/sorties. L'interactivité du système ne devrait donc pas en souffrir. Les LED des disques palpiteront gaiement.

Le processus de reconstruction est transparent et on peut utiliser le périphérique RAID pendant cette phase.

Formattez la matrice pendant la reconstruction. On peut également la monter et s'en servir. Bien sûr, si le mauvais disque lache à ce moment là, il ne s'agissait pas d'un jour de chance.

4.5 RAID-4

Remarque : je n'ai pas testé personnellement cette configuration et ce qui suit correspond à ce qui me paraît le plus vraisemblable.

On dispose de trois disques ou plus de taille sensiblement équivalente, l'un d'eux est nettement plus rapide que les autres et on souhaite les combiner en un périphérique de taille plus élevée tout en conservant un certain niveau de redondance. En outre, on peut introduire des disques de secours.

Fichier /etc/raidtab typique  :

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
Les disques de secours sont traités par les lignes suivantes  :
 device         /dev/sdf1
 spare-disk     0

La matrice s'initialise comme d'habitude  :

 mkraid /dev/md0

On se reportera aux options particulières de mke2fs avant de formater le périphérique.

4.6 RAID-5

On dispose de trois disques ou plus de taille sensiblement équivalente que l'on veut combiner en un périphérique de taille plus élevée tout en assurant la redondance des données. On peut introduire des disques de secours.

Si on employe N disques dont le plus petit est de taille S, la taille de la matrice sera (N-1)*S. L'espace manquant sert au stockage des données de parité (redondance). Si un disque tombe en panne, les données restent intactes. Si deux disques lachent, toutes les données sont perdues.

Fichier de configuration /etc/raidtab typique  :

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
Les disques de secours sont traités par les lignes suivantes  :
 device         /dev/sdh1
 spare-disk     0
Et ainsi de suite.

Une taille de bloc (chunk-size) de 32 ko est un bon choix par défaut pour de nombreux systèmes de fichiers. La matrice dérivée du fichier de configuration précédent est de 7 fois 6 Go soit 36 Go (n'oubliez pas que (n-1)*s = (7-1)*6 = 36). Il contient un système de fichiers ext2 avec une taille de blocs de 4 ko. Rien n'empèche d'aller au-delà via les paramètres de bloc de la matrice et du système de fichiers si ce dernier est plus grand ou s'il doit contenir des fichiers de grande taille.

A présent, on exécute  :

 mkraid /dev/md0
Normalement les disques devraient s'activer furieusement durant la construction de la matrice. On examinera le contenu du fichier /proc/mdstat pour savoir ce qui se passe.

Si le périphérique a été créé avec succès, la reconstruction est en cours. La matrice ne sera pas cohérente tant que celle-ci n'aura pas pris fin. La matrice est cependant parfaitement opérationnelle (à la gestion des défaillances près) et on peut déjà la formater et s'en servir.

On se reportera aux options particulières de mke2fs avant de formatter le périphérique.

Maintenant que le disque RAID fonctionne, on peut l'arrêter ou le redémarrer via les commandes  :

 raidstop /dev/md0
et
 raidstart /dev/md0

Au lieu de mettre ces commandes dans les scripts d'initialisation et de rebooter un milliard de fois pour arriver à tout faire fonctionner, on lira les paragraphes suivants qui traitent de l'autodétection.

4.7 Les superblocs persistants

Autrefois (TM), les utilitaires RAID analysaient le fichier de configuration et initialisaient la matrice. Il fallait donc que le système de fichiers sur lequel figurait le fichier /etc/raidtab soit monté  : plutôt pénible pour démarrer sur un système de fichiers RAID.

L'ancienne approche conduisait de surcroît à des complications pour monter des systèmes de fichiers reposant sur périphériques RAID. Ils ne pouvaient être simplement mis dans le fichier /etc/fstab habituel et nécessitaient des interventions chirurgicales dans les scripts de démarrage.

Les superblocs persistants résolvent ces problèmes. Lorsqu'une matrice est initialisée avec l'option persistent-superblock dans le fichier /etc/raidtab, un superbloc de type particulier est écrit au début de chaque disque prenant part à la matrice. Le noyau est alors capable d'obtenir directement la configuration de la matrice depuis les disques qui la composent au lieu de devoir analyser un fichier de configuration à la disponibilité aléatoire.

On gardera quand même cohérent le fichier /etc/raidtab puisqu'on peut en avoir besoin ultérieurement en cas de reconstruction de la matrice.

Les superblocs persistants sont obligatoires si on souhaite bénéficier de l'auto-détection des périphériques RAID au démarrage du système. On se reportera à la section Autodétection.

4.8 Taille des blocs (chunk size)

Ce paramètre mérite quelques explications. On ne peut jamais écrire de façon rigoureusement parallèle sur un ensemble de disques. Dans le cas de deux disques sur lesquels on devrait écrire un octet, on pourrait souhaiter que les quatres bits de poids fort aillent toujours sur le même disque, ceux de poids faible allant sur l'autre. Le matériel ne le permet pas. On définit donc de façon plus ou moins arbitraire une taille de bloc élémentaire qui correspondra à la plus petite quantité de données "atomique" qui sera écrite sur les disques. L'écriture de 16 ko avec une taille de bloc de 4 ko provoquera l'envoi du premier et du troisième bloc de 4 ko vers le premier disque et celui du deuxième et du quatrième bloc vers le second disque pour une matrice RAID-0 comportant deux disques. Pour de grosses écritures, la consommation de ressources sera minimisée par une taille de blocs importante tandis qu'une matrice composée essentiellement de petits fichiers profitera davantage d'une taille de blocs réduite.

Ce paramètre peut être spécifié pour tous les niveaux de RAID, même le mode linéaire où il n'a aucun effet.

A vous de modifier ce paramètre, ainsi que la taille de blocs du système de fichier, pour obtenir les meilleurs performances possibles.

L'argument de l'option chunk-size dans le fichier /etc/raidtab précise la taille en ko.

RAID-0

Les données sont écrites successivement sur chaque disque par paquets de chunk-size octets.

Pour une taille de bloc de 4 ko, lors de l'écriture de 16 ko de données sur un système muni de trois disques, la couche RAID écrira simultanément 4 ko sur chacun des trois disques puis écrira les 4 ko restant sur le disque 0.

32 ko semble un bon point de départ pour une majorité de matrices mais la valeur optimale dépend étroitement du nombre de disques impliqués, du contenu du système de fichiers et de divers autres facteurs. A vous d'expérimenter pour trouver la meilleure valeur.

RAID-1

Pour les écritures le paramètre importe peu vu que les données doivent être écrites sur tous les disques. Cependant, pour les lectures, il fixe la quantité de données à lire en une fois depuis un disque. Tous les disques contenant la même information, les lectures peuvent être équilibrées d'une façon similaire au RAID-0.

RAID-4

Lors d'une écriture dans une matrice RAID-4, l'information de parité doit être mise à jour sur le disque dédié. La taille de bloc spécifie alors la taille des blocs de parité. Si un octet est écrit dans une matrice RAID-4, chunk-size octets seront lus depuis N-1 disques, la parité sera calculée et chunk-size octets seront écrits sur le disque de parité.

Le paramète affecte les performances de la même façon que pour le RAID-0 puisque les lectures fonctionnent de la même façon.

RAID-5

Le paramètre a la même signification que pour le RAID-4.

128 ko est une valeur raisonnable. A vous de l'ajuster.

On se reportera également à la section traitant des options particulières de mke2fs qui affectent les performances du RAID-5.

4.9 Options de mke2fs

L'option -R stride=nn permet à mke2fs d'optimiser l'emplacement des structures de contrôle spécifiques à ext2 lors du formatage d'un disque RAID-4 ou RAID-5.

Si la taille de bloc RAID est de 32 ko, 32 ko de données consécutives résideront sur un même disque. Si on souhaite construire un systéme de fichiers ext2 avec une taille de blocs de 4 ko, il y aura 8 blocs de données consécutifs dans un bloc du tableau. On fournit l'information à mke2fs de la manière suivante  :

 mke2fs -b 4096 -R stride=8 /dev/md0

Les performances du RAID-{4,5} dépendent fortement de cette option. Je ne suis pas sûr de son influence sur les autres niveaux RAID. Si quelqu'un a des informations à ce sujet, elles seront les bienvenues.

La taille de bloc ext2 joue très fortement sur les performances du système de fichier. Dès que la taille de ce dernier dépasse quelques centaines de Mo, une taille de bloc de 4 ko est conseillée (à moins que le système de fichiers ne doivent stocker de très nombreux petits fichiers).

4.10 Autodétection

L'autodétection permet une reconnaissance automatique des périphériques par le noyau au démarrage, jsute après l'identification des partitions usuelles.

Requis  :

  1. La gestion de l'autodétection par le noyau.
  2. Les disques RAID doivent avoir été créés avec l'option de persistance des superblocs.
  3. Les partitions doivent être de type 0xFD (à positionner avec fdisk).

Remarque  : on vérifiera que la matrice RAID est arrêtée avant de changer le type des partitions (raidstop /dev/md0).

En suivant les trois étapes précédentes, l'autodétection devrait être en place. Essayez de redémarrer. Une fois le système initialisé, /proc/mdstat doit confirmer que la matrice RAID fonctionne.

Des messages semblables aux suivants apparaitront au démarrage  :

 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 reconstruction
Il s'agit des messages à l'autodétection des partitions d'une matrice RAID-5 qui n'a pas été arrêtée correctement (la machine a planté). La reconstruction a lieu spontanément. Le montage de l'unité est parfaitement licite puisque la reconstruction est transparente et que toutes les données sont cohérentes (seule l'information de parité qui ne sert qu'en cas de défaillance d'un disque est incohérente).

Les périphériques reconnus automatiquement sont stoppés de même quand le système s'arrête. Oubliez les scripts d'initialisation et servez vous des disques /dev/md comme s'il s'agissait de /dev/sd ou /dev/hd.

C'est aussi simple que ça.

Les lignes comportant les commandes raidstart et raidstop dans les scripts d'initialisation ne servent que pour les matrices RAID qui reposent sur l'ancienne mouture du code. Elles peuvent être supprimées sans hésitation dans le cadre de matrices RAID qui ont recours à l'autodétection.

4.11 Démarrage sur un disque RAID

Il existe plusieurs façons de mettre en place un système qui monte directement sa partition racine depuis un périphérique RAID. Pour l'instant, seuls les outils d'installation graphiques de la RedHat 6.1 permettent l'installation directe sur une matrice RAID. Il vous faudra donc surement effectuer quelques manipulations à la main mais il n'y a là rien d'impossible.

La dernière version officielle de lilo (21) ne gère pas les disques RAID et le noyau ne peut donc pas être chargé au démarrage depuis ce genre de périphériques. Il faudra donc que le répertoire /boot réside sur un système de fichier hors RAID. Afin d'être sûr que le système démarre quel que soit son état, dupliquez une partition /boot similaire sur chaque disque. Le BIOS sera ainsi toujours capable de charger les données depuis, par exemple le premier disque disponible. Il faudra donc que le système ne démarre pas avec un disque défectueux.

Avec la RedHat 6.1 est fourni un patch pour lilo 21 qui permet d'accéder à /boot sur du RAID-1. On notera que le patch n'est pas adapté aux autres niveaux RAID. Le patch est disponible dans tous les mirroirs RedHat via dist/redhat-6.1/SRPMS/SRPMS/lilo-0.21-10.src.rpm. La version modifiée de lilo acceptera un argument du type boot=/dev/md0 dans le fichier /etc/lilo.conf et rendra chaque disque du mirroir utilisable au dénarrage.

On peut également avoir recours à une disquette de démarrage.

4.12 Installer le système de fichiers racine sur une couche RAID

Deux méthodes sont fournies ci-dessous. A ma connaissance, aucune distribution ne permet l'installation sur un disque RAID et la méthode que je suggère suppose que vous installez d'abord le système sur une partition normale avant de mouvoir les fichiers sur la matrice RAID une fois l'installation complète.

Première méthode  :

On dispose d'un disque supplémentaire où on peut installer le système.

  • Installez un système normal sur le disque supplémentaire.
  • Mettez en place un noyau incluant les patches nécessaires pour le RAID et vérifiez que le système s'initialise correctement avec ce noyau. Il faudra veiller à ce que le support RAID soit dans le noyau et non sous forme de modules.
  • A présent, configurez et créez la matrice RAID dont vous comptez vous servir en tant que racine. Il s'agit de la procédure standard telle que décrite précédemment dans le document.
  • Redémarrez le système afin de vérifier que la matrice est détectée correctement (elle devrait en tout cas).
  • Créez un système de fichier sur la nouvelle matrice avec mke2fs et montez la en /mnt/newroot (par exemple).
  • Copiez le contenu de la racine courante sur le disque RAID. Il existe différentes façons de faire, par exemple  :
     cd /
     find . -xdev | cpio -pm /mnt/newroot
    
  • modifiez le fichier /mnt/newroot/etc/fstab de façon à ce qu'il pointe vers le périphérique /dev/md? adéquat pour la racine.
  • Démontez le répertoire /boot courant et montez le à la place en /mnt/newroot/boot.
  • Mettez à jour /mnt/newroot/etc/lilo.conf de façon à pointer vers le bon périphérique. Le périphérique de boot doit rester un disque normal (non-RAID) mais le disque racine doit pointer vers la matrice RAID. Ceci fait, exécutez un
    lilo -r /mnt/newroot
    
    . Lilo ne devrait pas émettre d'erreurs.
  • Redémarrez le système et admirez avec quel facilité tout se passe comme on le souhaite :o)

Dans le cas de disques IDE, on spécifiera dans le BIOS les disques comme étant de type ``auto-detect'' pour que la machine puisse redémarrer même si un disque manque.

Seconde méthode  :

Cette méthode nécessite l'emploi d'outils RAID et du patch qui autorisent la directive failed-disk. Il faut donc disposer d'un noyau 2.2.10 ou au delà.

Il faut que la matrice soit au moins de type 1. L'idée consiste à installer le système sur un disque marqué défectueux du point de vue RAID puis à copier le système sur la partie restante de la matrice RAID qui sera considérée comme dégradée avant de réinsérer le disque d'installation et de déclencher sa resynchronisation.

  • Installez un système normal sur un des deux disques (qui fera plus tard partie de la matrice). Il est important que ce disque ne soit pas le plus petit sans quoi il ne sera pas possible de l'ajouter à la matrice !
  • Récupérez le noyau, le patch, les outils, etc... Redémarrez le système avec le noyau qui est muni de la gestion RAID.
  • Créez votre matrice en indiquant le disque qui occupe la racine actuelle comme failed-disk dans le fichier raidtab Ne mettez pas ce disque en première position dans le fichier ou vous aurez du mal à démarrer la matrice. Activez la matrice et mettez y un système de fichiers.
  • Redémarrez et vérifiez que la matrice RAID est correctement activée.
  • Copiez les fichiers de la racine et modifiez les fichiers système du disque RAID de façon à ce qu'il se référence bien en tant que racine.
  • Lorsque le système démarre correctement depuis le disque RAID, modifiez le fichier raidtab en emplaçant la directive failed-disk par une directive raid-disk. Ajoutez à présent ce disque à la matrice avec raidhotadd
  • Le système doit à présent démarrer depuis une matrice non-dégradée.

4.13 Démarrer le système depuis le RAID

Pour que le noyau soit capable de monter le système de fichiers racine, les pilotes des périphériques nécessaires doivent être présents dans le noyau (NdT : ou chargés via un initrd qui peut également contenir les modules RAID).

La façon normale de procéder consiste à compiler un noyau qui inclut en dur toutes les options RAID nécessaires (NdT : je proteste !).

La redHat-6.0 étant fournie avec un noyau modulaire qui gère la nouvelle mouture du RAID, je vais cependant en décrire l'emploi si on souhaite s'en servir pour démarrer son systéme depuis un volume RAID.

Démarrage avec le RAID modularisé

Il faut préciser à lilo qu'il doit également charger un équivalent de ramdisk en sus du noyau au démarrage. La commande mkinitrd permet de créer un ramdisk (ici un initrd) contenant les modules nécessaires au montage de la racine. Commande type  :

 mkinitrd --with=<module> <ramdisk name> <kernel>
Par exemple  :
 mkinitrd --with=raid5 raid-ramdisk 2.2.5-22

Ceci garantit que le module RAID adéquat sera disponible au démarrage lorsque le noyau devra monter la racine.

4.14 Mises en garde

Ne repartitionnez JAMAIS un disque qui appartient à une matrice RAID. Si vous devez modifier la table des partitions d'un disque au sein d'une matrice, arrêtez d'abord la matrice et repartitionnez ensuite.

On a vite fait de saturer un bus. Un bus Fast-Wide SCSI courant n'offre que 10 Mo/s, ce qui est largement en dessous des performances des disques actuels. Mettre six disques sur un canal de ce type n'apportera bien entendu pas le gain en performances souhaité.

L'ajout de contrôleurs SCSI n'est susceptible d'améliorer les performances que si les bus déjà présents sont proches de la saturation. Vous ne tirerez rien de plus de deux contrôleurs 2940 si vous n'avez que deux vieux disques SCSI qui ne satureraient même pas un seul contrôleur.

Si vous omettez l'option de persistance des superblocs votre matrice ne redémarrera pas spontanément après un arrêt. Reprenez la création de la matrice avec l'option correctement positionnée.

Si la resynchronisation d'une matrice RAID-5 échoue après qu'un disque ait été oté puis reinséré, l'ordre des disques dans le fichier raidtab est peut-être le responsable. Essayez de déplacer la première paire ``device ...'' et ``raid-disk ...'' en début de description de la matrice.

La plupart des retours d'erreur observés sur la liste de diffusion linux-kernel proviennent de gens qui ont procédé à des mélanges douteux entre les patches et les outils RAID. Si vous utilisez le RAID 0.90, vérifiez que vous vous servez bien de la bonne version des utilitaires.


Page suivante - Page précédente - Table des matières