# [SAN] Redimensionner un disque à la volée

## Oupsman

Là je commence à désespérer ... 

Je m'explique : 

je présente une LUN de 10G à un serveur X86_64 sur le san et je cherche désespérément à l'augmenter à  500 Go (enfin du moins que fdisk le voit). 

J'ai présenté la LUN de 10G au serveur, créé une partition et un VG sur cette partition. Je crée les LV et les filesystems, bref tout comme il faut. 

Maintenant, je teste l'agrandissement du VG, par redimensionnement de la LUN sur la baie (HP). 

Le kernel ne voit pas la nouvelle taille, je fais un echo 1 > /sys/block/sdk/device/rescan (sdk étant la LUN vue par le serveur Linux)

Maintenant, ni fdisk, ni parted ne voit la nouvelle taille. 

Y'a-t-il une commande magique à passer pour que les outils de partitionnement voient la lumière ?

PS : Windows se comporte mieux que Linux sur ce coup là, d'où mon désespoir, les admins Windows se foutent de ma gueule   :Sad: 

----------

## Bapt

il faudra connaitre ta carte (Qlogic ?)

si c'est QLogic, il faut forcer un rescan par la carte :

echo "scsi-qlascan" > /proc/scsi/<driver-name>/<adapter-id>

Ensuite il faut refabriquer (rescan le scsi)

echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi

(0 1 2 3) correspond à ton "Host Channel ID LUN".

normalement fdisk devrait tout voir correctement ensuite les commandes classiques lvm et resize du fs

----------

## Oupsman

 *Bapt wrote:*   

> il faudra connaitre ta carte (Qlogic ?)
> 
> si c'est QLogic, il faut forcer un rescan par la carte :
> 
> echo "scsi-qlascan" > /proc/scsi/<driver-name>/<adapter-id>
> ...

 

Ah oui : 

j'ai de l'emulex. J'ai lancé la commande déclenchant le scan complet du san. Aucune mise à jour dans /proc/partitions. 

J'ai lancé la commande echo 1 > /sys/block/sdk/device/rescan et là /proc/partitions me remonte bien la bonne taille pour /dev/sdk

Mais un fdisk -l persiste à me remonter l'ancienne taille.

----------

## Bapt

un fois que tu as scanner ta carte emulex, il faut impérativement add-single-device sinon tu ne verras pas tes nouvelles lun sans un reboot (et encore)

----------

## Oupsman

la LUN est déjà présentée au serveur, je l'ai simplement redimensionnée. Et je voudrais que le noyau comprenne que je l'ai redimensionnée.

----------

## Mickael

Y'a une explication traduite pour les LUN sur ce fil : [TIP] Caméscopes "hybrides" et USB, et pour le noyau il ne faut pas oublier cette option :

 *Quote:*   

> Cependant, il ne faut pas oublier d'activer l'option Probe all LUNs on each SCSI device (SCSI_MULTI_LUN) dans le noyau, sinon, seul le LUN 0 (disque dur) sera activé et la carte mémoire (LUN 1) ne sera pas détectée. 

 

Regarde ce TIP ouvert par Ghoti cela devrait t'intéresser.

EDIT : EN plus j'avais écrit ceci en comment dans mon poste : 

 *Quote:*   

> 
> 
> COMMENT : cette solution manuelle est également très confortable pour toi administrateur réseau si tu rajoutes des devices sur ton serveur qui est en production. Il est alors possible d'avoir ces nouveaux devices sans stopper le module qui va bien et le redémarrer, donc pas d'arrêt du serveur. Regarder ici " Forcer un contrôleur QLogic à rescanner ses devices" avec la commande qui va bien : scsi-qlascan

 

----------

## babykart

Tu as démonté et renonté la lun dimensionnée?

[EDIT]le but est peut-être de ne pas démonter justement? [/EDIT]

----------

## Oupsman

Oui, le but est de ne pas arrêter la production pour agrandir l'espace disque. 

Chronologie : 

- création d'une LUN de 10 Go sur une baie du SAN (HP EVA)

- présentation au serveur

- reconnaissance de la lun (commande hp_rescan -a, on est en matos full-hp ... )

- création d'une partition sur toute la LUN

- création d'un PV à partir de cette partition

- création d'un VG sur ce PV

- création de 3 FS dans ce VG

- formatage et montage des FS

- agrandissement de la LUN sur la baie

- hp_rescan

- constatation du non-agrandissement de la LUN coté OS

- galère

- idée de génie : echo 1 > /sys/block/sdk/device/rescan

- /proc/partitions me donne bien la bonne taille pour sdk

- impossible d'agrandir cette foutue partition à chaud, parce que fdisk (ou parted ... ) persiste à donner 10Go comme taille à la LUN

- démontage des FS, désactivation du VG, blockdev -rereadpt pour relire la table des partitions et mettre à jour la taille de la LUN, redimensionnement de la partition avec fdisk (suppression/recréation) et réactivation du VG puis pvresize puis remontage des FS puis agrandissement des FS ! 

Mais si j'avais pu éviter de passer par la phase de démontage des FS et de fermeture du VG, je m'en porterais mieux quand la solution sera en production (donc peu de créneau d'arrêts)

----------

## Mickael

Salut, on dirait que ici cela fonctionne : ici. Y'a pas non plus une tonne d'explications, mais si cela te permet de trouver...

EDIT : tu dis : 

 *Quote:*   

> - démontage des FS, désactivation du VG, blockdev -rereadpt pour relire la table des partitions et mettre à jour la taille de la LUN, redimensionnement de la partition avec fdisk (suppression/recréation) et réactivation du VG puis pvresize puis remontage des FS puis agrandissement des FS ! 

 

Peut-être une piste : 

 *Quote:*   

> The problem is that if you have a real scsi controller - this won't have any
> 
> effect.  See, if you have scsi hardware mkinitrd will include mod_scsi in your
> 
> initial ramdisk - so the module will get loaded without being passed that parameter.
> ...

 

Et puis ici un tuto de chez IBM : Dynamic SAN fabric reconfiguration

----------

## Bapt

Tu as demandé le support HP vue que vous êtes full HP, j'ai fais un projet avec HP sur un énorme SAN et avec ce que je t'ai donné on avait aucun souci pour ce genre de manip.

----------

## Oupsman

Oui oui, le support HP m'a demandé de rebooter ....

Bapt : tu arrivais à REDIMENSIONNER une LUN ? Parce que l'ajout de périphériques SAN à chaud, ca va je maitrise.

----------

## Bapt

ouais mais on rebootais peut etre, je ne me souviens plus trop c'était il y a 3 ans  :Smile: 

----------

## Oupsman

 :Laughing:   :Laughing:   :Laughing:  Moi je dis ça c'est de l'évolution de stockage à chaud, si il y'a un reboot à prévoir   :Laughing:   :Laughing:   :Laughing: 

----------

## babykart

 *Oupsman wrote:*   

>    Moi je dis ça c'est de l'évolution de stockage à chaud, si il y'a un reboot à prévoir    

 

Dans le doute, à l'époque, c'est pour cette raison que je me suis orienté sur les techno NAS... attendu que je joue avec la volumétrie au moins une fois par semaine...   :Wink: 

----------

## Oupsman

Je ne désespère pas d'y arriver, j'ai eu une autre idée qui risque d'être bonne. Et comme je viens de rentrer un serveur identique au premier (Octocore, 16 Go de RAM), je vais pouvoir tester ...

----------

## dapsaille

Humm .. perso 

nous ajoutons une nouvelle lun 

que nous intégrons dans le vg ...

 ensuite aggrandissment du fs.

 Je vais demander à mes collègues storage demain de m'aggrandir une lun sur une vm de test pour voire si c'est faisable.. 

(j'ai un gros doute la)

----------

## Oupsman

 *dapsaille wrote:*   

> Humm .. perso 
> 
> nous ajoutons une nouvelle lun 
> 
> que nous intégrons dans le vg ...
> ...

 

Oui ça c'est la méthode standard, mais moi je voulais le faire comme sous Windows, histoire d'éviter d'être la risée de mes collègues  :Smile: 

----------

