J'ai un grave problème avec une baie de stockage SAN connectée à un boîtier Linux via Fibre Channel. Voici la configuration:
- Debian avec plain vanilla linux 2.6.27.25
- Contrôleur fibre optique QLogic 4Gb double port (basé sur ISP2432)
Fondamentalement, le problème est: comment obtenir ce #? @ !! Contrôleur / pilote FC pour reconnaître correctement les changements de configuration (LUN nouveaux ou supprimés) de la matrice de stockage?
- lorsque je crée un nouveau LUN sur ma baie (généralement un instantané de certains LUN existants) et que je le mappe sur mon HBA, je ne peux pas le faire reconnaître correctement:
rescan-scsi-bus -l -w -rdétecte réellement quelque chose (un périphérique générique / dev / sgXX) mais aucun périphérique de bloc est créé (/ dev / sdXX). même chose lors de l'émission d'un LIP et d'une nouvelle analyse manuelle:
echo 1> / sys / class / fc_host / host6 / issue_lip
echo "- - -"> / sys / class / scsi_host / host6 / scan
si je supprime un LUN existant, aucune émission de LIP et de nouvelle analyse ou rescan-scsi-bus n'a d'effet. Les appareils précédents restent là et bien sûr ne fonctionnent pas ("file -s / dev / sdXX -> I / O error").
- le rechargement du pilote qla2xxx fonctionne. Cependant, il est totalement irréalisable dans un environnement de production.
Apparemment, c'est un problème très courant avec QLogic . Il existe une sorte de solution qui fonctionne uniquement lors de l'utilisation du pilote émis par QLogic disponible uniquement pour les distributions d'entreprise RedHat et Suse: voir cette explication .
Information additionnelle :
Voici les périphériques scsi avant LIP et rescan:
# sg_map -x
/dev/sg0 0 0 0 0 0 /dev/sda
/dev/sg1 0 0 1 0 5 /dev/scd0
/dev/sg2 1 0 0 0 0 /dev/sdb
/dev/sg3 6 0 0 0 0 /dev/sdc
/dev/sg4 6 0 0 1 0 /dev/sdd
/dev/sg5 6 0 0 2 3
Après une LIP et une nouvelle analyse, j'ai un nouveau périphérique sg, mais pas de lecteur correspondant. Si je recharge le pilote, un lecteur apparaît:
# sg_map -x
/dev/sg0 0 0 0 0 0 /dev/sda
/dev/sg1 0 0 1 0 5 /dev/scd0
/dev/sg2 1 0 0 0 0 /dev/sdb
/dev/sg3 6 0 0 0 0 /dev/sdc
/dev/sg4 6 0 0 1 0 /dev/sdd
/dev/sg5 6 0 0 2 3
/dev/sg6 6 0 0 3 3
~# sg_map -x
/dev/sg0 0 0 0 0 0 /dev/sda
/dev/sg1 0 0 1 0 5 /dev/scd0
/dev/sg2 1 0 0 0 0 /dev/sdb
/dev/sg3 8 0 0 0 0 /dev/sdc
/dev/sg4 8 0 0 1 0 /dev/sdd
/dev/sg5 8 0 0 2 0 /dev/sde
/dev/sg6 8 0 0 3 3
Edit: OK, évidemment, c'est un écrou difficile à casser. Je vais demander au LKML et faire un rapport ici.