URL: https://linuxfr.org/users/3tus/journaux/migrer-vers-un-ssd-simplement-avec-lvm Title: Migrer vers un SSD simplement avec lvm Authors: Lionel Draghi Date: 2013年12月31日T18:55:00+01:00 License: CC By-SA Tags: ssd, lvm, migration et openoffice Score: 82 [ref_SSD]:http://fr.wikipedia.org/wiki/Solid-state_drive [ref_NAS]:(http://fr.wikipedia.org/wiki/Stockage_en_r%C3%A9seau_NAS) [ref_LVM]:http://fr.wikipedia.org/wiki/Gestion_par_volumes_logiques [ref_LV]:http://fr.wikipedia.org/wiki/LVM#Volumes_logiques_LV [ref_VG]:http://fr.wikipedia.org/wiki/LVM#Groupes_de_volumes_VG [ref_PV]:http://fr.wikipedia.org/wiki/LVM#Volumes_physiques_PV Quoi, encore un tuto sur les SSD? ================================= Allez, cette fois ci c'est décidé, je saute le pas : j'ai investi deux cents euros dans un bon disques [SSD][ref_SSD], et je remplace mon [[RAID1]] de 250 Go. Mes deux disques vont finir dans un boîtier [NAS][ref_NAS] qui servira de backup familial. J'ai lu pas mal d'articles sur le sujet, mais j'ai rapidement compris qu'il fallait se méfier des informations d'il y a ne serait-ce que deux ans, car tant les [SSD][ref_SSD] que le kernel ont pas mal évolués pour prendre en compte les particularité de ces disques qui n'en sont pas. Pourtant certains des points techniques sont repris à l'envie par d'autres articles plus récents, qui donnent l'impression d'une information à jour. Mais je ne t'apprend rien : il y a 30 ans le problème c'était de trouver de l'information, maintenant le problème c'est de trouver la bonne. Ce que je vais te raconter ici, c'est une expérience de migration complète d'un Linux sur un [LVM][ref_LVM], lui même sur un [[RAID1]], vers un disques [SSD][ref_SSD] avec des modifications pas anodines au passage. Une situation plutôt complexe (pour un PC personnel), mais une migration qui va s'avérée d'une grande simplicité grâce à [LVM][ref_LVM]. Enfin bon, simplicité, on se comprend, hein! Mon article est un peu long parce que j'ai essayé d'être pédagogue et parce que j'y aborde pas mal de chose. Et aussi parce que je suis un peu bavard, il faut bien le reconnaître. Quoi qu'il en soit, j'espère que sa lecture te fera gagner du temps. Considérez juste ça : j'ai installé le [SSD][ref_SSD], j'ai démarré mon Linux, j'ai fait ce qui est décrit ci-dessous, et au boot suivant c'était pleinement opérationnel, et j'ai pu retirer mes deux anciens disques durs. Pas de boot sur un CD ou une clé USB live, pas le moindre _chroot_, pas presque pas de tripatouillage de fstab, même pas un reboot... Tiens, c'est bien simple, si on m'abordait dans la rue pour me le proposer, je demanderai ou est la caméra. Quel est le principe? ===================== La beauté de [LVM] (Logical Volume Manager, http://fr.wikipedia.org/wiki/Gestion_par_volumes_logiques), c'est de gérer des volumes *logiques* décorrélés des volumes *physiques*. En clair, au lieu de manipuler directement des partitions, on va maintenant manipuler des [LV][ref_LV] (Logical Volume). Par exemple, mon _/home_ sera un [LV][ref_LV], mais il n'est pas directement lié à une partition : il peut s'étaler sur plusieurs partitions de plusieurs disques. Et bien sûr, [LVM][ref_LVM] fournit les outils qui vont bien pour gérer tout cela, y compris le fait d'étendre un [LV][ref_LV] à de nouvelle partition, ou le fait d'en libérer une. Avant d'en venir au principe de la manip, fixons le vocabulaire utile, car toutes les commandes commencent par [PV][ref_PV], [VG][ref_VG] ou [LV][ref_LV], donc autant savoir une fois pour toute de quoi il retourne. Dans l'ordre ascendant en niveau d'abstraction : - [PV][ref_PV], volume physique, c'est une partition ou un disque; - [VG][ref_VG], groupe de volume physique ; - [LV][ref_LV], volume logique, que l'on insère dans un [VG][ref_VG], et que l'on formate et monte comme nos anciennes partitions. Voilà le principe que j'ai utilisé pour ma migration depuis mes disques classiques vers mon [SSD][ref_SSD] : 1. extension du groupe de volume qui contient (toutes mes partitions dans la configuration de départ) au disque [SSD][ref_SSD]; 1. déplacement des données vers le [SSD][ref_SSD] / libération des disques d'origines; 1. ajustements du boot (et oui, **tout** est passé d'un disque à l'autre), des tailles de partitions (le disque cible est un peu plus grand que le disque origine), et de quelques autres réglages liés à la différence de nature entre DD et [SSD][ref_SSD]. Notez que tout cela n'a été possible que parce que mon Linux actuel est *déjà* installé sur un [LVM][ref_LVM]. Par quoi on commence? ===================== Pour commencer ces travaux avec enthousiasme et confiance, il nous faut une musique en accompagnement plutôt entraînante et gaie. DJ Lio te conseille les _Modern Talking - You're My Heart, You're My Soul_, dont la mise en plis ne devrait pas avoir bougée même 30 ans après. D'abord, on créé un volume physique sur le [SSD][ref_SSD] (chez moi : _/dev/sda_) : `# pvcreate --dataalignment=4M /dev/sda` Et `pvscan` nous permet de voir la situation : `# pvscan` PV /dev/md0 VG Aurora_VG lvm2 [233,63 GiB / 0 free] PV /dev/sda1 lvm2 [238,47 GiB] Total: 2 [472,11 GiB] / in use: 1 [233,63 GiB] / in no VG: 1 [238,47 GiB] C'est fou ce qu'il y a comme info en 3 lignes! La première décrit mon système actuel : un [VG][ref_VG] nommé _Aurora_VG_ (nom arbitraire, je fais ce que je veux) qui rempli un [PV][ref_PV] constitué d'un RAID /dev/md0. La deuxième décrit le [PV][ref_PV] constitué du SDD. La premier [PV][ref_PV] est plein comme un boudin, le second est vide comme les caisses de l'état. Ça ne va pas durer, au moins pour mon [SSD][ref_SSD]. Pour être manipulable comme un tout, les deux [PV][ref_PV] doivent être affectés au même groupe de volume. Ajoutons donc le nouveau [PV][ref_PV] au [VG][ref_VG] existant : `# vgextend Aurora_VG /dev/sda` Si on refait un coup de `pvscan`, on voit que le [SSD][ref_SSD] est bien lui aussi maintenant dans le [VG][ref_VG] Aurora_VG : `# pvscan` PV /dev/md0 VG Aurora_VG lvm2 [233,63 GiB / 0 free] PV /dev/sda1 VG Aurora_VG lvm2 [238,47 GiB / 238,47 GiB free] Total: 2 [472,11 GiB] / in use: 2 [472,11 GiB] / in no VG: 0 [0 ] On aurait aussi pu vérifier avec la commande `vgdisplay` que notre [VG][ref_VG] a maintenant une taille égale à la somme des deux [PV][ref_PV] : `# vgdisplay -C` VG #PV #LV #SN Attr VSize VFree Aurora_VG 2 3 0 wz--n- 472,11g 4,84g Le vol des octets migrateurs ============================= Mais y a bien un moment dans la manip ou il faut faire des copies physiques. Eh ben c'est maintenant. DJ Lio te conseille un grand café et une musique pas trop nostalge, sinon, ça parait vraiment long. Pour moi se sera une séquence _System of a Down - Chop Suey_, suivi de _Green Day - American Idiot_. Étant donné la durée de l'opération, il est probable que te puisse écouter tout l'album. `# pvmove /dev/md0 /dev/sda1` Mais ce qui est formidable avec [LVM][ref_LVM], c'est que le système reste opérationnel pendant cette migration qui n'a rien d'anodine. Je suis par exemple en train d'écrire ces lignes pendant que défile dans un terminal les lignes indiquant la progression du `move`, du type : /dev/md0: Moved: 23,6% Je te déconseille d'entreprendre de grandes manœuvres en même temps, sauf a vraiment aimer rendre les choses risquées et encore plus longues. Mais toi dont le mot de passe est _banzai_, je sais que tu ne m'écouteras pas. Soit. Puisque tu insistes, il y a bien quelques autres petites choses stratégiques à faire en attendant. Et note que la commande `lvs` te permettra de voir à tout moment ou tu en es : `# lvs -o +devices` LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Devices Home Aurora_VG -wI-ao--- 195,57g pvmove0(0) Root Aurora_VG -wI-ao--- 34,34g pvmove0(51020) Swap Aurora_VG -wI-ao--- 3,72g pvmove0(50067) Et en attendant, qu'est-ce qu'on fait? ====================================== Nan, j'le ferai pas! -------------------- J'ai fait pour ma part des choix tenant compte de l'évolution des disques [SSD][ref_SSD] récents, et pris du coup moins de précautions que ce que tu verras dans la plupart des autres tutoriaux de migration vers [SSD][ref_SSD] pour éviter des cycles rapides d'écritures sur des zones précises du file system. J'ai par exemple gardé ext4 et décidé de ne pas toucher à la journalisation. De même, je ne ferai pas d'effort spécifique pour déplacer en RAM le cache du navigateur ou d'apt. Je ne veux pas non plus de perte fonctionnelle quelconque, et je n'ai pas déplacé /var/log, /var/spool ou /var/tmp en RAM. Swap pas la tête? ----------------- J'ai également décidé de garder ma partition de swap. Néanmoins, pour un investissement modeste (en regard du [SSD][ref_SSD]), j'ai passé ma mémoire vide de 4 à 8 Go. Je suppose que le système ne devrait plus avoir que très exceptionnellement besoin du swap. Du coup, j'ai décidé de passé /tmp en RAM, avec une capacité max de 2 Go, et ajouté dans /etc/fstab : tmpfs /tmp tmpfs defaults,size=2g 0 0 noatime/relatime/Ballantine's ----------------------------- Pendant que j'avais le nez dans fstab, j'aurai pu tripatouillé le fameux paramètre noatime/relatime, ou même plus largement vouloir renoncer à un file system journalisé. Conformément à la politique que j'ai donné au-dessus, je n'en ai rien fait. Avant de suivre sur ce sujet les conseils donnés dans d'autres tutoriaux du même ordre, je te conseille de lire [le billet de Ted Tso sur le sujet] (http://tytso.livejournal.com/61830.html). Ça donne une idée des coûts relatifs en écritures du atime et du journaling. swappiness/Guiness ------------------ Un autre sujet récurrent lorsque l'on parle migration sur [SSD][ref_SSD] est le swap. Parlons-en. Le comportement par défaut du kernel avec le swap (décrit [ici](http://en.wikipedia.org/wiki/Swappiness)) est de faire appel au swap dès que 60% de la mémoire vive est utilisée, plutôt de de relâcher des pages mémoires en mémoire cache. Une façon de rendre le kernel plus agressif avec ses ressources RAM, (et donc de moins utiliser de swap) est de réduire ce pourcentage, éventuellement à 0. Dans ce dernier cas, le kernel n'utilisera le swap que pour éviter un "out of memory". C'est le choix que j'ai fais, d'autant plus tranquillement qu'avec mes 8 Go de RAM pour un usage personnel, je pense que le kernel n'aura pas besoin d'être si agressif que ça dans la chasse au page mémoire. Pour savoir ou tu en es en terme de "swappiness" : `# cat /proc/sys/vm/swappiness` Pour changer ce paramètre maintenant : `# sudo sysctl -w vm.swappiness=0` Mais surtout, pour qu'il soit passé au kernel à chaque reboot, il faut insérer dans votre _/etc/sysctl.conf_ : vm.swappiness=0 T'as le kernel agressif? relâche la pressure! --------------------------------------------- Dans une situation normale (disque dur, et RAM pas sur-abondante), il peut être intéressant d'ajuster simultanément le paramètre vm.vfs_cache_pressure, car si on rend le kernel agressif avec la récupération de la mémoire en général, il faut quand même préserver la mémoire allouée aux caches des file system, qui sont très important pour les performances. Grâce à ce paramètre, on fait en sorte que la pression au paging out mise sur le kernel s'applique moins aux pages allouée au cache du file system. Je ne l'ai pas fait, car j'ai supposé qu'avec ma RAM importante, un [SSD][ref_SSD] qui est naturellement plus rapide et qui possède sa propre mémoire cache, ça ne devrait pas changer grand chose. Pour ma part, j'ai la flemme d'expérimenter la-dessus pour l'instant. Je t'invite néanmoins à lire cet article très intéressant sur le sujet : [Tales from responsivenessland: why Linux feels slow, and how to fix that] (http://rudd-o.com/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that). Tu auras l'argumentaire de l'auteur, et surtout les manips qui permettent de tester l'effet de ces paramètres, si tu souhaite expérimenter. elevator, deadline, cfq? Une aspirine s'il te plaît. ---------------------------------------------------- Concernant le sujet de l'ordonnanceur d'I/O : là également, je ne vais pas prendre le temps de faire des expériences, et j'ai décidé de passer au kernel _elevator=deadline_, en changeant _GRUB_CMDLINE_LINUX_DEFAULT="elevator=deadline quiet splash"_ dans _/etc/default/grub_, sans oublier `updade grub` ensuite pour que ce soit pris en compte. Pour savoir ou tu en es sur ce paramètre : # cat /sys/block/sda/queue/scheduler L'algo deadline classe les blocks à écrire par ordre de priorité, en fonction de la priorité du process qui demande l'I/O, mais à la différence de l'algo utilisé par défaut (cfq), il essaie de linéariser les écritures, et il se permet donc d'écrire des blocs moins prioritaire, si c'est sur son chemin. Je ne suis pas sûr que se soit déterminant ni pour limiter les écritures (et donc l'usure), ni pour les performances, mais bon, ça m'arrive de suivre les conseils! J'attire juste votre attention sur un point : si votre device possède un cache et une certaine intelligence, ce qui est le cas a priori d'un [SSD][ref_SSD], alors il essaie probablement aussi de son côté d'ordonnancer intelligemment les écritures. Dans ce cas, la CPU consommée par le kernel dans un algo d'I/O pas trivial n'est peut-être pas utilement utilisée, et il vaut peut-être mieux retomber sur l'algo de base du kernel (noop), et laisser le device faire ce travail. A expérimenter! On cause, on cause, et pendant ce temps là... =============================================== Finalement, le move est finis, Glory Allelouia! (DJ Lio envoie aussitôt "Docteur Alban", il est incorrigible!) Un `lvs` nous permet de constater la nouvelle situation : `lvs -o +devices` LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Devices Home Aurora_VG -wi-ao--- 195,57g /dev/sda1(0) Root Aurora_VG -wi-ao--- 34,34g /dev/sda1(51020) Swap Aurora_VG -wi-ao--- 3,72g /dev/sda1(50067) Tout est sur sda1, md0 n'est plus utilisé. **Achtung : nous sommes maintenant vraiment en danger** : le système est instable, avec un [[MBR]] pas à jour. Il ne faut surtout pas rebooter. Deux conseils de bases : 1. n'approchez pas à moins de 3 mètre du bouton reset de l'ordi, un geste regrettable est si vite arrivé. 1. si quelqu'un chez toi envisage de lancer le lave-vaisselle alors qu'il y a déjà le lave-linge et le four qui tournent, tu as autorisation de lui faire mal, car il ne faut pas coupure d'électricité. Métaphoriquement parlant, il vaut mieux péter les plombs avant que le disjoncteur ne le fasse. C'est pas clair ma métaphore? Laisse tomber... Comme tu vis avec exaltation ce moment de grand danger, DJ Lio te conseille de t'accompagner de 'Baltimora - Tarzan Boy'. En jetant un coup d’œil à mon fstab, les bonnes surprises continuent. Comme j’utilisai déjà [LVM][ref_LVM], mes root, home et swap sont déjà désignés en tant que [[UUID]], ou comme _/dev/mapper/Aurora_VG-Root_ par exemple, si tu n'utilises pas les [[UUID]]. Il n'y a plus de référence à des devices spécifiques, type /dev/hd1, donc rien à changer! 20 ans de tripatouillage de fstab à chaque petite modifications du système font que j'ai encore du mal à croire que la partition root à changée de disque sans que je touche fstab! Je verse une larme sur la beauté du monde, et passe rapidement à la suite avant que DJ Lio ne nous mette du _Barbara_. Et Grub dans tout çà? ===================== En regardant les devices connus de [[Grub]], par la commande `# cat /boot/grub/device.map` : (hd0) /dev/disk/by-id/ata-Maxtor_7V250F0_V59979FG (hd1) /dev/disk/by-id/ata-Maxtor_6V250F0_V591PGTG On trouvera mon ancienne situation (les deux disques en RAID1). Mettons Grub à jour la dessus: `# grub-mkdevicemap` `# cat /boot/grub/device.map` (hd0) /dev/disk/by-id/ata-PLEXTOR_PX-256M5Pro_P02340110360 (hd1) /dev/disk/by-id/ata-Maxtor_6V250F0_V591PGTG (hd2) /dev/disk/by-id/ata-Maxtor_7V250F0_V59979FG On voit que le [SSD][ref_SSD] Plextor est venu s'insérer en hd0, et que les deux DD ont changé d'ordre du fait de mon recâblage au hasard sur la carte mère. Mais qu'à celà ne tienne, car comme je l'ai dit plus haut, grace aux [[UUID]] et/ou au [devmapper (Device Mapper)](http://en.wikipedia.org/wiki/Device_mapper) il n'y a plus de hd1 à manipuler directement! Ensuite on roule les classiques : `# update-grub` `# grub-install /dev/sda` Si tu veux vérifier que grub va bien passer au démarrage du kernel la partition root, regarde ton _/boot/grub/grub.cfg_. Pour moi, il y a un volume logique spécifique "Root" dans le grouppe de volume "Aurora_VG", et on a bien une ligne : linux /boot/vmlinuz-3.11-2-amd64 root=/dev/mapper/Aurora_VG-Root ro elevator=deadline quiet splash Et si le vrai luxe c'était l'espace? ==================================== Tiens, mais au fait, mon disque [SSD][ref_SSD] est légèrement plus grand que mes DD d'origines, qu'est devenue la différence? Rien! J'aurai peut-être pu y penser avant, mais qu'à celà ne tienne, non seulement la commande `lvresize` va me permettre de redimensionner un de mes volume logique, mais en plus avec l'option `--resizefs` elle va aussi gérer le redimensionnement du file system. Je lui demande donc d'attribuer 100% de l'espace libre à mon [LV][ref_LV] "Home" : `# lvresize --resizefs --extents +100%FREE Aurora_VG/Home /dev/sda1` Extending logical volume Home to 200,41 GiB Logical volume Home successfully resized resize2fs 1.42.8 (20-Jun-2013) old_desc_blocks = 13, new_desc_blocks = 13 Et `lvs` me le prouve, mon [LV][ref_LV] Home est bien passé de 195 à 200 GiB : `# lvs` LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Home Aurora_VG -wi-ao--- 200,41g Root Aurora_VG -wi-ao--- 34,34g Swap Aurora_VG -wi-ao--- 3,72g Bon, je crois qu'on est pas mal, là. Va falloir rebooter. Je sais, ca fait peur, mais faut sauter. *** J'y crois pas! ============== Oh bordel, ça marche du premier coup!! C'est une des premières fois que ça m'arrive en 20 ans de charcutage de Linux! Un coup de `df` pour voir ou en sont mes file system : `# df` Sys. de fichiers blocks de 1K Utilisé Disponible Uti% Monté sur /dev/mapper/Aurora_VG-Root 35307176 5972884 27517716 18% / udev 10240 0 10240 0% /dev tmpfs 406032 724 405308 1% /run tmpfs 5120 0 5120 0% /run/lock tmpfs 1592740 84 1592656 1% /run/shm /dev/mapper/Aurora_VG-Home 206719640 30228204 166020472 16% /home tmpfs 2097152 8 2097144 1% /tmp Tout est normal, plus de swap, et tmp est en RAM. J'en reviens pas. Et tout ça pour quoi? ===================== Et je vais faire court sur l'essentiel : ça tient ses promesses, ca va vite, très vite. Linux se lance en un instant, et Gnome aussi. À tel point que le lancement du BIOS parait comparativement très long. Pareil pour le navigateur, pour OpenOffice, etc. C'est finis, et ça marche. Rends toi à l'évidence, tu es le plus beau et le plus fort : DJ Lio te conseille de mettre à fond le grand _Plastic Bertrand - ça plane pour moi_, et surtout de hurler avec lui _I'm the king of the divan_!! Tu l'as bien mérité. Dans le cas contraire, j'essaierai de t'aider... (Oh bon dieux, mais pourquoi j'ai dit ça!!) Lionel PS : si tu as des questions sur les [SSD][ref_SSD], [LVM][ref_LVM] ou la swapiness, je ne garanti rien. Mais si tu ne sais plus qui a chanté "Vanina rappelle toi que je ne suis rien sans toi", tu peux compter sur moi!

AltStyle によって変換されたページ (->オリジナル) /