JBOD deplacement de donnée pour enlever disque

obeone · Le 21/11/2012, à 00:37

Bonjour à tous,
J'ai actuellement un JBOD, si j'en enlève le dernier disque les données se trouvant dessus seront perdu, comment faire pour que ces données soit déplacée sur les disques que je souhaite garder en vu du démontage de ce disque et de la réduction de l'array?
Merci.

tiramiseb · Le 21/11/2012, à 17:23

Salut,

Peux-tu donner plus de détails sur ton JBOD ?
C'est un terme générique qui ne décrit pas précisément la technologie matérielle ou logicielle que tu utilises, du coup on ne peut pas te répondre.
C'est géré en matériel sur ton ordinateur ? Dans un NAS ? C'est du LVM ? Autre chose ?

obeone · Le 21/11/2012, à 22:59

Hum, s'pas faux ce que tu dis
JBOD créé avec mdadm, pas du LVM, ext4, je vois rien d'autre.. ha si ubuntu 10.04 64bits.

Dernière modification par obeone (Le 21/11/2012, à 23:00)

tiramiseb · Le 22/11/2012, à 07:50

Ah malheureusement je n'utilise pas mdadm, je ne peux donc pas te donner de jolie solution toute faite

Pour ma part je travaille énormément avec LVM, qui donne une plus grande flexibilité et pour lequel j'aurais su te donner des précisions
(d'ailleurs pour une éventuelle prochaine install je te conseille d'utiliser LVM)

Je peux tout de même te donner 2 ou 3 généralités (que tu connais peut-être déjà, mais mieux vaut prévenir que guérir) :
- un volume de stockage contient un système de fichier (une partition n'est pas égale à un système de fichier, c'est son contenant)
- par conséquent, avant de réduire la taille d'un volume (que ce soit une partition, un volume logique LVM, un volume MD...), il faut réduire la taille du filesystem à l'intérieur (avec la commande resize2fs)
- et, à l'inverse, après avoir augmenté la taille d'un volume il faut penser à augmenter la taille du filesystem

À ce que j'ai lu tu peux utiliser mdadm --fail pour marquer un disque en erreur puis mdadm --remove pour le supprimer de ta grappe... Mais je ne sais pas comment tu peux t'assurer que les données ne sont plus stockées sur ce disque.

Hoper · Le 22/11/2012, à 13:46

JBOD créé avec mdadm, pas du LVM, ext4, je vois rien d'autre.. ha si ubuntu 10.04 64bits

gné !? Mais c'était quoi le but ? faire du jbod avec mdadm !? C'était vraiment une TRES mauvaise idée à la base ça...

Accessoirement, tu te trompe, Si tu retire sans précautions un disque dans un jbod, ce ne sont pas juste les données de ce disque que tu va perdre, mais forcément l'ensemble des données (perte de la structure du FS).

Je ne savais même pas qu'mdadm offrait cette possibilité, mais il existe en effet un mode "linéar" et je suppose que c'est de cela dont il est question... Franchement, il faudra que je me renseigne pour comprendre l’intérêt de cette chose, parce que la comme ça, par rapport à volume group lvm, il n'y a vraiment que des inconvénients. Inconvénients dont tu as d'ailleurs sous les yeux un bon exemple...

Un rapide coup d'oeil sur google confirme qu'il n'est pas du tout prévu de pouvoir retirer un disque sur un raid0 ou un jbdod. (Que ferait mdadm des données présentes !? Comment peut il savoir ce qui est réellement utilisé sur le disque ou pas ? Il n'a pas la connaissance de la couche système de fichier, il ne gère que la couche bloc device). mdadm est la pour gérer des raids, par pour faire de la gestion de disque et de volume.
Ca c'est le travail de LVM...

Bon, comme je trouvais ça intéressant quand même comme cas de figure, j'ai un peu creusé. J'ai reproduit chez moi la problématique, en utilisant trois volume comme si il s'agit de 3 disques pour faire mon jbod.

J'ai ensuite copié des données dessus, et j'ai finalement pu réussir à retirer un disque et à conserver les données... C'est vraiment, mais alors vraiment sans garanties...

Création du jbod :

root@gemeaux:/backup/cam# lvcreate -n f1 -L 32m /dev/ovg
  Logical volume "f1" created
root@gemeaux:/backup/cam# lvcreate -n f2 -L 32m /dev/ovg
  Logical volume "f2" created
root@gemeaux:/backup/cam# lvcreate -n f3 -L 32m /dev/ovg
  Logical volume "f3" created
root@gemeaux:/backup/cam# mdadm --create --chunk=32 --level=linear -n3 /dev/md1 /dev/ovg/f1 /dev/ovg/f2 /dev/ovg/f3
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.

root@gemeaux:/backup/cam# mkfs -t ext4 /dev/md1
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
23808 inodes, 95232 blocks
4761 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
12 block groups
8192 blocks per group, 8192 fragments per group
1984 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 35 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
root@gemeaux:/backup/cam#
root@gemeaux:/backup/cam# mount /dev/md1 /mnt

A partir de la j'ai donc rempli totalement le FS avec plein de données (remplissage à 100%) puis j'en ai supprimé pour ne plus avoir que quelques Mo de données. A partir de ce moment la, il faut réduire suffisament le FS pour qu'il puisse intégralement tenir A COUP SUR, sur l'ensemble des disques moins celui que tu veux retirer ET IL FAUT ABSOLUMENT RETIRER LE DERNIER DISQUE, cela ne fonctionnera avec aucun autre !

Coila ce que j'ai fait :

root@gemeaux:/# umount /mnt
root@gemeaux:/# resize2fs /dev/md1 60M
resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/md1' first.

root@gemeaux:/# e2fsck -f /dev/md1
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md1: 1566/23808 files (0.2% non-contiguous), 12507/95232 blocks
root@gemeaux:/# resize2fs /dev/md1 60M
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/md1 to 61440 (1k) blocks.
The filesystem on /dev/md1 is now 61440 blocks long.

Le FS fait maintennat 60M et tiens donc théoriquement sur les deux premiers "disques".
On tente le retrait du troisième :

root@gemeaux:/# mdadm --remove /dev/md1 /dev/ovg/f3
mdadm: hot remove failed for /dev/ovg/f3: Device or resource busy

Meme en forçant, il n'est pas possible de supprimer le disque.
On tente la méthode violente :

root@gemeaux:/# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@gemeaux:/# mdadm  --assemble --force /dev/md1 /dev/ovg/f1 /dev/ovg/f2
mdadm: /dev/md1 assembled from 2 drives - not enough to start the array.

Impossible de le ré-assembler de cette façon...
On essaye alors la méthode du tout pour le tout, l'ultime violence :

root@gemeaux:/# mdadm --zero-superbloc /dev/ovg/f1 /dev/ovg/f2 /dev/ovg/f3
root@gemeaux:/# mdadm --create --chunk=32 --level=linear -n2 /dev/md1 /dev/ovg/f1 /dev/ovg/f2
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@gemeaux:/# mount /dev/md1 /mnt

root@gemeaux:/# du -sh /mnt/*
3.8M    /mnt/etc
12K     /mnt/lost+found

Dans mon cas, c'est passé.... Et j'ai retrouvé les 3,8 Mo de données que j'avais laissé sur le FS. Mais c'est évidement EXTREMEMENT violent comme methode, et je ne te garenti strictement rien. Ce n'est pas parce que chez moi cela à fonctionné que cela n'aboutira pas, chez toi, à la perte
de toutes tes données, surtout si tu fais la moindre erreur de manipulation au cours de la manip

Sincèrement tu ferai beaucoup mieux de sauvegarder toutes tes données, et de reconstruire un raid propre et exploitable. Si tu veux simplement concaténer des disques (et pouvoir en ajouter ou en retirer comme ça te chante, ce n'est pas mdadm qu'il faut utiliser mais LVM). Tu trouvera dans la documentation ubuntu et sur mon blog une documentation assez complète et orienté "débutant complet". N'hésite pas à t'en servir...

PS : La réponse de tiramiseb (que je n'avais pas lu) était déjà très bonne, et décrivait parfaitement les problématique. La plus grosse étant que mdadm n'a aucun contrôle sur l'endroit ou son stocker les données (contrairement à LVM). C'est pour cela que ma "méthode" ne fonctionnera que pour retirer le dernier disque (la commande resize2fs diminue logiquement la taille en réduisant à partir de la fin du disque, qu'il soit logique ou physique).

Dernière modification par Hoper (Le 22/11/2012, à 17:36)

obeone · Le 22/11/2012, à 20:34

En réponse à Tiramiseb, oui procédure que j'ai utilisé lors de l'agrandissement de mon jbod par 2 fois, mais tu fais bien de le dire, un topic n'est pas à l'usage unique de son auteur

Hoper je sais pas si je vais te pardonner
Bon allez, peut être bien que si vu que tu as pris la peine de rédiger cette superbe prose
J'y jette un oeil sérieusement, je ferai du retour après.
En tout état de cause, pour avoir déjà fait "joujou" avec du RAID, les données vraiment importantes seront 'backupées' avant toute manip.

Merci à vous deux.

[Edit]
J'aimerai revenir sur la commande mdadm --zero-superbloc, quelle est sa portée ?

Dernière modification par obeone (Le 22/11/2012, à 20:39)

Hoper · Le 22/11/2012, à 20:51

J'aimerai revenir sur la commande mdadm --zero-superbloc, quelle est sa portée ?

Suppression totale de toutes les meta données du raid.
imagine que tu veuille complétement effacer le MBR d'un disque, tu va le remplir de zéero (et ton disque ne pourra plus booter). Et bien la, tu vais la meme chose, mais au niveau du raid... En gros, après cette commande, le raid n'existe vraiment plus, et un mdadm --examine sur les devices ne te donnera plus rien.

Pour le "pardonne moi mais..." j'ai édité car je sais que j'ai été un peu violent, mais je suis comme ça, j'ai tendance à écrire ce que je pense cache, et c'est ce que j'ai pensé en lisant ton post. Après, objectivement, j'ai évidement vu des choses bien pires dans ma vie

Dernière modification par Hoper (Le 22/11/2012, à 20:52)

obeone · Le 23/11/2012, à 23:47

Ok, donc lors de la "recréation" du raid, très important de bien mettre les disques dans l'ordre dans lequel ils était précédemment au risque ce coup ci de perdre toutes chance de récupération.

obeone · Le 24/11/2012, à 21:10

Après une lecture à tête reposé j'ai bien intégré ce que tu dis et le process utilisé, juste une question, après avoir vidé une partie du JBOD afin que le volume de données restant soit inferieur ou égale au volume de stockage moins le futur disque qu'on enlève, les données étant écrites n’importe ou, est-ce la commande resize2fs qui gérera le déplacement des données stocké sur le disque qu'on va retirer vers le reste du JBOD? (je sais pas si je suis bien clair ).

J'ai fait un petit tour par la case LVM, très intéressant, j'imagine qu'il doit exister des GUI afin de débuter tout en douceur, j'ai rien contre la ligne de commande bien au contraire, mais j'aimerai appréhender le tout correctement dans un premier temps.

tiramiseb · Le 24/11/2012, à 21:37

est-ce la commande resize2fs qui gérera le déplacement des données stocké sur le disque qu'on va retirer vers le reste du JBOD?

La commande resize2fs va faire en sorte que ton filesystem prenne la place que tu lui auras indiqué, en partant du début du volume et d'un bloc. Donc a priori, le JBOD que tu utilises étant totalement linéaire, si tu réduis de plus que la taille du dernier volume alors tu peux être quasi-sûr que le dernier disque sera vide. Enfin, je crois. Probablement. This is free advice with ABSOLUTELY NO WARRANTY. :-)

J'ai fait un petit tour par la case LVM, très intéressant, j'imagine qu'il doit exister des GUI afin de débuter tout en douceur

Je sais pas trop, je trouve les GUI trop compliquées...

obeone · Le 24/11/2012, à 22:44

Les GUI c'est pas trop mon truc non plus
J'ai lu différentes choses grâce à notre ami yahoort, et je vais suivre l'idée de Hoper, j'ai donc recréé à l'identique mon serveur (OS/RAID/SMB/etc) hormis la taille des disques sous virtualbox.
Je vais faire un peu joujou avec ça afin de valider un process qui sera fiable à 99,9% voir plus.

Dernière modification par obeone (Le 24/11/2012, à 22:47)

Hoper · Le 25/11/2012, à 12:09

L'idée, c'est de bien réduire le FS de (beaucoup) plus que nécessaire. Ne pas prendre de risques quoi. Par exemple si tu avais 3 disques de 1 To, il faudrait résuire le FS à 1,5 To ou un truc dans le genre. Du coup, on est sur de pouvoir supprimer un disque de 1 To (et donc n'en avoir plus que 2) sans soucis.

Ensuite, une fois le disque retiré et le jbod reconstruit sur 2 disques, le FS fera toujours 1,5 To au lieu de 2, mais il suffira de relancer la commande resize2fs pour qu'il occupe de nouveau tout l'espace (2To) disponible.

obeone · Le 25/11/2012, à 14:30

Oui c'est bien ce que j'ai lu un peu partout, j'ai testé d'autres méthodes que la tienne, mais sur un raid linéaire il n'est pas possible de réduire la taille comme sur du RAID 1 par exemple.
Ta méthode sous virtual box fonctionne impecc, je l'utiliserai donc pour mon NAS, en prenant tout de même soin de sauvegarder les données les plus importantes au cas ou.
Sinon pour la réduction, j'pense pas qu'il y ait besoin de réduire autant, 10% suffit largement surtout dans le cas de disques de 2TB ça laisse déjà une belle marge. Après on est bon en math ou non, dans le deuxième cas on risque purement la perte du FS.

obeone · Le 10/12/2012, à 16:04

Petit retour qui pourrait être utile.

En effet lorsqu'on fait le premier resize qui permet de réduire la taille du FS BIEN FAIRE ATTENTION à utiliser les bonnes unités (enfin surtout une universel), la meilleure option étant de calculer par block (corrigez moi si je me trompe).
Pour ma part j'ai pris le GB et je m'en suis mordu les doigts... et ce malgré 1.5Go de marge, donc attention l'utilisation des unités MB GB TB peut poser quelques déconvenues.

Mais tout n'est pas perdu.

Suite à ce souci, impossible de monter le FS, forcement la taille du FS était plus importante que la taille total des disques.
J'ai essayé de revoir la taille du FS en lui donnant une valeur correct plus petite que la taille réelle, opération qui se solde par un échec, j'étais donc parti sur l'idée que c'était fichu, et puis je me suis dit, si on ne peut pas réduire la taille du FS puisque celui ci n'est pas correct, peut être qu'en remettant le disque en place et en agrandissant le FS cela fonctionnerait... BINGO

J'ai donc repris la manip de Hoper en sens inverse.

mdadm --zero-superbloc /dev/sdb /dev/sdd /dev/sdc /dev/sde /dev/sdf
mdadm --create /dev/md1 --chunk=64 --level=linear --raid-devices=5 /dev/sdf /dev/sdd /dev/sde /dev/sdc /dev/sdb
mdadm: /dev/sdf appears to contain an ext2fs file system
    size=-725614592K  mtime=Fri Nov 30 15:51:02 2012
Continue creating array? y
mdadm: array /dev/md1 started.
resize2fs /dev/md1
resize2fs 1.41.11 (14-Mar-2010)
Le système de fichiers de /dev/md1 est monté sur /mnt ; le changement de taille soit être effectué en ligne
old desc_blocks = 469, new_desc_blocks = 583
En train d'effectuer un changement de taille en ligne de /dev/md1 vers 2441893120 (4k) blocs.
Le système de fichiers /dev/md1 a maintenant une taille de 2441893120 blocs.

Pour ma part le resize ne peut se faire qu'en ligne (raid monté pour les non initiés)

Bref tout est rentré dans l'ordre, me reste plus qu'a refaire la manip en utilisant une taille correct de block...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 21/11/2012, à 00:37

JBOD deplacement de donnée pour enlever disque

#2 Le 21/11/2012, à 17:23

Re : JBOD deplacement de donnée pour enlever disque

#3 Le 21/11/2012, à 22:59

Re : JBOD deplacement de donnée pour enlever disque

#4 Le 22/11/2012, à 07:50

Re : JBOD deplacement de donnée pour enlever disque

#5 Le 22/11/2012, à 13:46

Re : JBOD deplacement de donnée pour enlever disque

#6 Le 22/11/2012, à 20:34

Re : JBOD deplacement de donnée pour enlever disque

#7 Le 22/11/2012, à 20:51

Re : JBOD deplacement de donnée pour enlever disque

#8 Le 23/11/2012, à 23:47

Re : JBOD deplacement de donnée pour enlever disque

#9 Le 24/11/2012, à 21:10

Re : JBOD deplacement de donnée pour enlever disque

#10 Le 24/11/2012, à 21:37

Re : JBOD deplacement de donnée pour enlever disque

#11 Le 24/11/2012, à 22:44

Re : JBOD deplacement de donnée pour enlever disque

#12 Le 25/11/2012, à 12:09

Re : JBOD deplacement de donnée pour enlever disque

#13 Le 25/11/2012, à 14:30

Re : JBOD deplacement de donnée pour enlever disque

#14 Le 10/12/2012, à 16:04

Re : JBOD deplacement de donnée pour enlever disque

Pied de page des forums