Posts Tagged ‘raid’

Fichier special /dev/megaraid0 pour les noyaux Linux récents

Sunday, May 10th, 2009

En février 2008, la gestion du fichier spécial pour le management des cartes SCSI Megaraid (en général, /dev/megaraid0) a changé dans le noyau Linux. Auparavant, on notait la présence de megadev dans /proc/devices, car un numéro majeur (et dynamique) de périphérique lui était attribué. Les différents scripts utilisaient donc des scripts ressemblant à :

MAJOR=`grep megadev /proc/devices|awk '{print $1}'`
mknod /dev/megadev0  c $MAJOR 0

Mais un numéro majeur ne semblait pas utile, car seul un fichier spécial est nécessaire (même avec plusieurs cartes Megaraid) et le numéro mineur n’était jamais utilisé. Cela a donc changé à partir du noyau Linux 2.6.25, et c’est désormais un numéro mineur (et dynamique) et un numéro majeur correspondant à misc qui définit le périphérique /dev/megaraid0. On retrouve ainsi des bugreports chez Debian (#399783) et Gentoo (#233295) à propos de ce changement.

Concrètement, ce matin lors d’une mise-à-jour d’un noyau Linux de 2.6.21 en 2.6.28, le fichier spécial /dev/megaraid0 avec les numéros majeur/mineur 253/0 n’était plus utilisable par les outils de management du RAID. La suppression de ce fichier et l’installation d’udev a permis de retrouver un /dev/megaraid0 fonctionnel.

Pseudo-cartes RAID DELL/Adaptec

Saturday, February 23rd, 2008

Mon histoire avec les cartes Adaptec (Dell OEM) 39320 Ultra320 SCSI adapter commence il y a trois ans quand j’ai eu à installer plusieurs exemplaires de machines DELL PowerEdge SC420 incluant cette carte. Cette carte est sensée permettre du RAID hardware mais c’est loin d’être le cas. Les premiers drivers pour cette carte ont été inclus dans le noyau Linux 2.6.11 (l’installation de Sarge nécessitait donc une technique annexe : debian-installer avec un noyau custom ou debootstrap à partir d’un autre disque) mais ils ignorent tout simplement la configuration RAID effectuée au niveau du BIOS de la carte. Celle-ci gère pourtant le RAID0 et RAID1 mais au démarrage de Linux, les disques sont vus par le noyau comme des disques indépendants… Bref, pas de RAID hardware possible (des blobs pour Suse/RedHat existent mais je préfère éviter cette solution).

Récemment, j’ai du ajouter un nouveau disque sur ce controleur. J’ai donc branché ce 2e disque sur la machine concernée et tenté de démarrer la machine : le controleur ne trouvait pas de périphérique de démarrage valide. En regardant de plus près, il cherchait un volume RAID0, forcément inexistant. Or, je souhaitais simplement avoir deux malheureux disques, sans RAID. Mais même en retirant le disque ajouté, il cherchait toujours un volume RAID0 : le second disque devait contenir un reste de RAID0 et le controleur l’a considéré maître et et a écrasé la configuration du premier disque. Youpi : bien que le RAID de ce controlleur ne fonctionne pas sous Linux… me voilà coincé à cause du RAID. Premier réflexe : désactiver les fonctionnalités RAID de la carte, et la documentation d’Adaptec m’indique que c’est simple, il suffit de l’indiquer dans le BIOS de la carte. Sauf que j’ai une carte DELL/Adaptec, c’est-à-dire que DELL a placé un firmware modifié pour faire croire à une carte DELL et, au passage, a eu la chouette idée de supprimer la possibilité de désactiver le RAID. Arrivé ici, on pourrait penser qu’il suffit de mettre un firmware Adaptec mais c’est justement indiqué que l’on ne doit le faire qu’avec les cartes 100% Adaptec et non issues d’un autre fournisseur. Et de toute façon, cela risquerait de me faire perdre la garantie DELL, ultime recours en cas de soucis :-)

Je vais donc devoir me débrouiller avec ce firmware. Ma première mission est de ré-initialiser le RAID du premier disque car, avec controleur on ne peut pas effacer la configuration RAID, il faut… ré-initialiser complètement le disque (ce qui l’efface au passage). À noter que cette ré-initialisation peut être délicate, j’ai déjà explosé un disque SCSI en annulant cette opération ! À noter aussi que cela prend plusieurs heures et si l’on ajoute les temps de backup (dd powered), ça fait beaucoup de temps pour effacer quelques octets dans le firmware du disque dur… Ces opérations de réparation prennent donc des heures et des heures et un message de confirmation aurait ainsi été bienvenu avant que le controleur écrase ses fameux paramètres RAID stockés sur un disque.

En conclusion, lorsque l’on manipule les disques de volumes RAID, outre la possibilité de perdre les données, il faut bien avoir en tête le temps considérable que peuvent prendre certaines opérations, d’autant plus quand il s’agit de controleurs de qualité médiocre (qui impliquent souvent des fonctionnalités réduites).