Sommaire
- Quoi, encore un tuto sur les SSD?
- Quel est le principe?
- Par quoi on commence?
- Le vol des octets migrateurs
- Et en attendant, qu'est-ce qu'on fait?
- On cause, on cause, et pendant ce temps là…
- Et Grub dans tout çà?
- Et si le vrai luxe c'était l'espace?
- J'y crois pas!
- Et tout ça pour quoi?
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, et je remplace mon RAID1 de 250 Go.
Mes deux disques vont finir dans un boîtier 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 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, lui même sur un RAID1, vers un disques 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.
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, 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, 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 (Logical Volume). Par exemple, mon /home sera un 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 fournit les outils qui vont bien pour gérer tout cela, y compris le fait d'étendre un 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, VG ou LV, donc autant savoir une fois pour toute de quoi il retourne.
Dans l'ordre ascendant en niveau d'abstraction :
- PV, volume physique, c'est une partition ou un disque;
- VG, groupe de volume physique ;
- LV, volume logique, que l'on insère dans un 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 :
- extension du groupe de volume qui contient (toutes mes partitions dans la configuration de départ) au disque SSD;
- déplacement des données vers le SSD / libération des disques d'origines;
- 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.
Notez que tout cela n'a été possible que parce que mon Linux actuel est déjà installé sur un 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 (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 nommé Aurora_VG (nom arbitraire, je fais ce que je veux) qui rempli un PV constitué d'un RAID /dev/md0.
La deuxième décrit le PV constitué du SDD.
La premier 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.
Pour être manipulable comme un tout, les deux PV doivent être affectés au même groupe de volume.
Ajoutons donc le nouveau PV au VG existant :
# vgextend Aurora_VG /dev/sda
Si on refait un coup de pvscan, on voit que le SSD est bien lui aussi maintenant dans le 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 a maintenant une taille égale à la somme des deux 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, 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 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 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), 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.
Ç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 est le swap. Parlons-en.
Le comportement par défaut du kernel avec le swap (décrit ici) 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 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.
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, 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 :
- n'approchez pas à moins de 3 mètre du bouton reset de l'ordi, un geste regrettable est si vite arrivé.
- 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, 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 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) 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 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 "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 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, 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!
# Coïncidence
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Amusant : j'ai effectué exactement la même chose il y a deux jours, et je comptais écrire un article, un peu plus bref sans doute, à ce sujet. Je compte toujours l'écrire, parce qu'il sera en anglais et plus ciblé je pense.
Seule différence dans mon cas : je démarre en UEFI. À part ça, même résultat : je migre à chaud, je redémarre et ça marche du premier coup.
[^] # Re: Coïncidence
Posté par zebra3 . Évalué à 3.
Pareil, je l'avais fait aussi il y a bien un an et j'étais déjà supris que ça marche aussi bien.
Mais le plus fort, c'est quand même qu'on peut arrêter la migration avec un control+c et la reprendre plus tard où elle s'était arrêtée. Testé en live :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# MBR sans partition
Posté par Gilles Mocellin . Évalué à 2.
Attention, au début, tu as créé un PV directement sur le disque (/dev/sda) et non une partition.
Idem quand tu l'ajoute au VG.
Après, on voit bien qu'en fait c'etait /dev/sda1.
En effet, je ne pense pas cru que grub s'installe sans écraser le debut du PV, qui ne sera plus détecté.
Sinon, très bien LVM. Et je connais encore des gens qui évitent, pretextant qu'une couche supplementaire, c'est des risques en plus et des perfs en moins…
[^] # Re: MBR sans partition
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Quelle différence avec 2 partitions monté, une copie de l'un vers l'autre, et un reboot avec changement de la table de partition ?
"La première sécurité est la liberté"
[^] # Re: MBR sans partition
Posté par claudex . Évalué à 6.
La différence, c'est que tout ce qui est écrit pendant ou après la migration est conservé.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: MBR sans partition
Posté par paulez (site web personnel) . Évalué à 3.
Si pendant ta copie tu modifies une donnée déjà copiée et une autre non-copiée sur la source, après l'opération la destination contiendra des données incohérentes. Infaisable à chaud donc.
[^] # Re: MBR sans partition
Posté par Zenitram (site web personnel) . Évalué à 0.
L'auteur dit "j'ai installé le SSD, j'ai démarré mon Linux".
Ca veut donc dire qu'il peut faire à froid (il peut se permettre un arrêt de service, et il n'a pas fait de branchement à chaud, et même il reboot ensuite).
A partir de la, il n'y a pas de raison de modifier des données pendant la copie (au pire, un live CD pour jouer avec les partitions trnnaquille), donc la raison qui sous-entend qu'il y a un besoin de faire à chaud ne tient pas (encore une fois, suivant ce qu'on lit du journal, je vois évidement bien l'interêt de ce genre de proécédure sur un serveur ne devant jamais être arrété et avec baies hot plug)
Reste le plaisir du fun d'avoir testé, je conviens :)
[^] # Re: MBR sans partition
Posté par paulez (site web personnel) . Évalué à 3.
Ça évite aussi de devoir démarrer sur un autre système (live-cd) pour faire la copier du système de fichier /.
Et c'est quand même plus agréable de pouvoir continuer à mouler sur LinuxFR plutôt que de devoir aller voir ce qu'il se passe IRL à cause d'une copie de disque trop lente.
[^] # Re: MBR sans partition
Posté par barmic . Évalué à 3.
LVM apporte une souplesse agréable. Ne serait-ce qu'avoir son terminal et son éditeur préféré et configuré pour faire toutes ces actions est un plus bien agréable.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: MBR sans partition
Posté par steph1978 . Évalué à 2.
Il a dit ne pas s'être lancé dans de grandes opérations pendant la copie.
Mais c'est quand même appréciable de continuer à mouler ou à produire pendant la copie de données.
[^] # Re: MBR sans partition
Posté par Lionel Draghi (site web personnel) . Évalué à 1.
Bien vu!
En effet, j'ai commencé les manips sans avoir en tête de le raconter, et j'ai reconstitué le début de l'histoire ensuite, avec l'historique des commandes.
De mémoire, j'avais ouvert gparted au début (et aussi un petit outils graphique lvm : system-config-lvm, pour me rassurer) et j'ai du faire une unique partition primaire sur le SSD avec gparted.
# noatime et deadline
Posté par patrick_g (site web personnel) . Évalué à 10.
Je ne comprends pas très bien pourquoi tu a décidé de ne pas passer en noatime. C'est bénéfique sur le plan de la quantité d'écriture sur le disque et il n'y a aucun inconvénient…sauf si tu es utilisateur de Mutt, le fameux mouton noir de noatime, puisque ce MUA utilise la date de dernier accès pour vérifier le spool.
Franchement ça vaut le coup (cf le bench de Ted Ts'o).
En revanche je suis plus circonspect sur le changement de l'ordonnanceur des I/O. C'est beaucoup plus délicat d'estimer le bénéfice potentiel de deadline pour les SSD. Moi je préfère en rester à l'algo par défaut. Au moins je suis sûr qu'il est testé à fond et qu'il marche bien dans la plupart des cas.
[^] # Re: noatime et deadline
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
relatime rulez.
[^] # Re: noatime et deadline
Posté par patrick_g (site web personnel) . Évalué à 8.
Non, il rulez rien du tout.
De Ted Ts'o :
[^] # Re: noatime et deadline
Posté par Lionel Draghi (site web personnel) . Évalué à 2.
Et voilà, c'est le problème quand on publie presque deux mois après avoir fait le travail : je ne me rappelle plus de tous les pourquoi des arbitrages.
Je n'ai en effet pas vu de référence à un autre logiciel que Mutt qui présenterait une dépendance à la date de dernier accès.
Si les bench de Ted Ts'o sont sans ambiguïté sur les gains en performance, j'aurai du faire en toute logique ce choix.
Bon, finalement, que se soit pour cette question ou pour celle de l'algo d'ordonnancement, il nous faut un bench.
Je m'y attelle!
[^] # Re: noatime et deadline
Posté par Psychofox (Mastodon) . Évalué à 3.
Certains logiciels de backup (exemple symantec netbackup) utilisent les atimes pour gérer les incrémentaux.
[^] # Re: noatime et deadline
Posté par Lionel Draghi (site web personnel) . Évalué à 2.
Bon, voilà, j'ai fais un script qui déroule des "make" en balayant les trois paramètres possibles sur mon kernel : noop, deadline, cfq.
J'ai pris pour "stresser" un peu mon SSD ce qui traînait dans mon home, la recompilation des exemples de la libgtkada, ce qui génère un usage intensif de gcc.
Les résultats sont anormalement identiques, en particulier le temps perçu par l'utilisateur (voir première colonne ci-dessous).
Ça me laisse perplexe.
J'y vois deux explications possibles :
- ma façon de changer l'algo n'est pas prise en compte au vol par le kernel, et donc j'ai fait tous les tests avec le même algo;
- ces optimisations n'ont réellement aucun impact sur des systèmes aussi petit que les notre, et même une grosse compilation ne secoue pas vraiment le bouzin, car les caches du kernel, le tmpfs en RAM, le cache du SSD et son propre réordonnancement des écritures aplatissent les résultats.
Mon programme de test (qui fait donc 27 secondes de compilations), n'est sans doute pas assez gros.
D'un autre côté, j'ai trouvé un article qui comparait les temps de compilations du kernel, et pareil, il n'y avait pas de différences notables :
Linux I/O schedulers benchmarked - anticipatory vs CFQ vs deadline vs noop
Et là, on parle de 9 minutes de compilation…
Des idées?
De mon côté, il ne reste plus qu'a le refaire tourner avec noatime, pour voir.
Le voici, libre à vous de le faire tourner chez vous :
[^] # Re: noatime et deadline
Posté par Zenitram (site web personnel) . Évalué à 2.
Si j'ai bien suivi, c'est utile surtout pour les HDD (disques durs) (=pas des SSD), les SSD étant complètement différents et leur technologie étant cachée à l'OS, ça me semble logique que le temps soit pareil (dans tous les cas, le SSD a sa couche de "traduction").
Il faudrait aussi un vrai test de stress avec des accès lecture/écriture capable de remplir la queue d'I/O.
Vu les perfs des SSD, toujours complètement différent de disques durs, je parie que tu ne verras rien sur les tests de durée.
Ted compare la taille écrite sur le SSD, ce n'est pas pour rien : tu essayes de chatouiller un SSD capable de centaines de milliers d'IOPS avec quelques centaines d'IOPS de stress au mieux (oups) à peine avec du multi-tache basique, le SSD a largement le temps d'écrire le atime. Il faudrait encore un vrai test de stress.
L'interêt de désactiver le atime est de ne pas tuer le SSD à écrire trop souvent dessus, car un SSD veillit beaucoup plus vite (suivant la echnologie, un cellule de SSD peut supporter "que" quelques milliers d'écritures) qu'un HDD et plus tu écris dessus, plus il aura des chances de mourir (ça va dépendre ensuite de la taille de réserve que ton constructeur a pris pour les remplacements de secteurs morts, morts car on a trop écrit dessus)
[^] # Re: noatime et deadline
Posté par tatrefthekiller . Évalué à 1.
Tu oublies le filesystem cache. Ajoutes ça au début de ta boucle :
echo 3 > /proc/sys/vm/drop_caches
De plus je ne vois pas où est utilisé ta variable "j" (ou alors c'est pour faire plusieurs essais ?). Tu ne voulais pas faire un "make -j 1", "make -j 2"… ? Comme dit plus bas, il faudrait remplir la queue, en utilisant un grand nombre de compilations parallèles, mais du coup, tu risques d'être limité par le CPU. Un bon gros "make -j 64" devrait suffire !
[^] # Re: noatime et deadline
Posté par Lionel Draghi (site web personnel) . Évalué à 1.
Merci pour le truc,je vais essayer.
Pour éviter aux lecteurs de chercher comme je viens de le faire, echo 3 dans ce paramètre free pagecache, dentries and inodes.
Maintenant, le but étant d'évaluer l'impact de certain réglages relatifs au SSD sur les performances dans des conditions réelles, là on s'en éloigne un peu.
Au pire la première compilation sera plus lente que les suivantes, mais quant on code, on en fait en général quelques une à la suite, donc au total l'impact ne devrait pas être marquant.
Le j c'est par réflexe, je ne voulais pas m'en servir dans la boucle.
Mais ton idée d'un -j64 est excellente (quoi que je doute que gcc arrive à en faire autant en // sur ce code pas si gros que ça).
J'essaierai avec ces deux modifs.
[^] # Re: noatime et deadline
Posté par Ambroise . Évalué à 3.
Et encore, pour Mutt, c'est uniquement si tu utilises Mutt avec des boites au lettres au format mbox. Si tu passes en maildir, le problème disparaît.
Et il y a une méthode de contournement mis en place dans la 1.5.15 pour ce problème (voir FAQ) en re-compilant Mutt avec un paramètre.
# juste, wouah, un journal qui vaut son pesant de caracteres.
Posté par NeoX . Évalué à 10.
Juste pour dire que c'est bien ecrit,
que ca se lit bien, et c'est didactique.
bravo.
[^] # Re: juste, wouah, un journal qui vaut son pesant de caracteres.
Posté par Lionel Draghi (site web personnel) . Évalué à 3.
Merci, ça fait plaisir à lire!
# Sauf que...
Posté par fcartegnie . Évalué à 4.
Si LVM permet de passer les commandes discard (TRIM) du fs au SSD, il n'en garde par mémoire.
Dans l'opération, tu as déplacé et donc écrit N extents de ton LVM vers ton SSD.
Tu te retrouves donc avec un SSD qui a des blocs marqués comme utilisés pour tout l'espace libre + utile de ton FS d'origine.
T'aurais mieux fait dans ce cas de creer un nouveau Volgroup sur le SSD et de faire une copie de FS à FS optimisé SSD.
[^] # Re: Sauf que...
Posté par Xfennec (site web personnel) . Évalué à 2.
A priori, un appel à fstrim après la copie sur le SSD va rétablir la situation, non ? (à moins que cette commande ne fonctionne qu'en "relatif" par rapport à son dernière appel … auquel cas il existe peut-être un moyen de refaire une passe complète)
[^] # Re: Sauf que...
Posté par Lionel Draghi (site web personnel) . Évalué à 2.
Alors là, tous les deux vous m'avez satellisé!
[^] # Re: Sauf que...
Posté par Florian Hatat . Évalué à 2.
D'après le man fstrim :
Je pense donc également qu'un fstrim fait bien une passe complète sur tous les blocs.
[^] # Re: Sauf que...
Posté par barmic . Évalué à 2.
Puisque tu en parle le TRIM est-il possible à travers un LVM ? (je crois qu'il y avait un problème à ce niveau à une époque)
Tu pense à qui ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# plus de RAID ?
Posté par -mat . Évalué à 3.
Est ce bien raisonnable de laisser tomber le RAID ? Le SSD peut toujours tomber en rade du jour au lendemain….
[^] # Re: plus de RAID ?
Posté par Lionel Draghi (site web personnel) . Évalué à 4.
J'ai un rdiff-backup qui tourne tous les soirs sur un DD dédié au backup, donc une panne totale n'aurait pas d'effet catastrophique.
Mais surtout, cela rejoint les considération générales sur la fiabilité des SSD : je pense qu'on a maintenant un recul suffisant (mais je me fait peut-être des idées…) pour supposer que leur fiabilité est supérieure à celle des DD classique, et ce sur une durée raisonnablement longue.
Par ailleurs, j'ai bien regardé les retour d'expérience sur les SSD, et j'ai choisi un beau modèle (pas à un prix plancher), sans problème connu de fiabilité.
Je ne suis donc pas plus inquiet que ça!
[^] # Re: plus de RAID ?
Posté par Richard Genoud . Évalué à 4.
Ayant pas mal travaillé avec les mémoires de type NAND, j'ai du mal à faire confiance aux SSD, et je serais plutôt de l'avis contraire (mais c'est peut être parce que je ne connais pas si bien les disques rotatifs).
C'est sûr que niveau chocs, fiabilité mécanique, les SSD sont forcément devant, mais par contre, le stockage lui même (les chips NAND), ça fait vraiment peur… (badblocks, durée de vie ultra limitée des blocks, bitflips à la pelle).
[^] # Re: plus de RAID ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu oublies le wear leveling, les codes correcteurs d'erreurs, …
"La première sécurité est la liberté"
[^] # Re: plus de RAID ?
Posté par Richard Genoud . Évalué à 3.
C'est ce à quoi je pensais en citant "vie ultra limitée des blocks" (d'où le besoin de faire du wear leveling) et "bitflips à la pelle" (d'où le besoin d'utiliser des codes correcteurs d'erreurs).
D'ailleurs, j'imaginais que sur les SSD, on mettait de la NAND type SLC, mais a fortiori, c'est plutôt de la MLC voire de la TLC.
Et c'est pas très glorieux en terme de longévité.( de l'ordre du millier d'écriture pour 1 block :/ ).
Bref, personnellement, quand je passerai au SSD, je n'abandonnerai surtout pas mon RAID1.
[^] # Re: plus de RAID ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Dans les derniers technos les plus fines, j'ai lu plutôt 100 écritures par bloc. C'est aussi pourquoi il y a autant de spares dans les ssd.
"La première sécurité est la liberté"
[^] # Re: plus de RAID ?
Posté par barmic . Évalué à 2.
« supérieure » ? Je n'ai pas vu d'info aller dans ce sens. J'aurais dis que c'est pas pire (si on prend quelque chose d'un peu sérieux en tous cas).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: plus de RAID ?
Posté par Zenitram (site web personnel) . Évalué à 3.
Taux de retour des HDD
Taux de retour des SSD
Et de souvenir (je ne retrouve pas les liens rapidos), sur le long terme (plus de 1 an) c'est du même style voire mieux pour les SSD et ça va en s'améliorant.
Bref, une fois que tu évites les marques pourries (en SSD, il y a des modèles à éviter absolument, la marque top dans les retour ayant d'ailleurs coullé à cause d'une réputation sur le sujet, et en HDD il y a eu aussi des séries maudites), on ne peut pas dire que les SSD sont si horribles, voir c'est carrément mieux, vraiment "supérieure" (en moyenne on peut dire SSD 2x mieux que HDD une fois les marques non sérieuses enlevées?).
# En passant par le chemin de mon SSD
Posté par moi1392 . Évalué à 10.
Cette phrase m'a paru bizarre : "il se permet donc d'écrire des blocs moins prioritaire, si c'est sur son chemin."
De ce que j'en avais compris à l'époque des disques dur (avec de vrais morceaux de disque à l'intérieur), quand on parlais de "sur le chemin", il s'agit du chemin de la tête de lecture.
Mais puisque qu'un ssd n'a plus de tête de lecture qui se promène, cela ne correspond plus à rien.
Il y a un truc que je n'ai pas compris dans l'histoire ?
[^] # Re: En passant par le chemin de mon SSD
Posté par barmic . Évalué à 1.
Ça doit tout de même permettre de grouper les écritures sur le média.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: En passant par le chemin de mon SSD
Posté par Lionel Draghi (site web personnel) . Évalué à 2.
En fait, ce n'est pas dans le cas du SSD une optimisation de performance, mais une optimisation de durée de vie.
Ma compréhension est qu'avec l'algo deadline, il y a moins de chance de se trouver dans la situation d'une écriture de bloc, suivie dans la milliseconde de la réécriture du même bloc parce que un second write a été fait sur d'autres octets dans la même zone.
Pour les DD on voulait optimiser le point faible : la mécanique. Pour les SSD on veut réduire les write, mais le principe reste le même, regrouper les écritures par bloc.
Bien sûr, je n'ai aucun moyen de vérifier si cela a un impact réel sur la durée de vie, c'est pourquoi je disais faire confiance (même si ce cas pathologique de réécriture me semble un peu théorique).
Pour ma référence à l'expérimentation à la fin de ce même paragraphe, je pensais à l'algo noop : les premiers tests, qu'il faut prendre avec des pincettes, semble en effet confirmer que cet algo plus simple donne les mêmes performances que les deux autres sur un SSD.
Mais d'un autre côté, sa simplicité n'occasionne pas des gains de CPU substantiels qui à leur tour amélioreraient les performances (ce qui est normal, puisque sur nos PC de bureau, SSD ou pas SSD la CPU n'est toujours pas le maillon faible, l'optimiser dans les coins ne sert donc pas à grand chose).
Après, si quelqu'un veut dérouler le script donné plus haut sur un DD pour voir si ce paramètre change les choses, ce pourrait être intéressant dans les situation mixte DD/SSD car on peut faire un choix d'algo différent par device.
# Avec encore moins d'interruption
Posté par benoar . Évalué à 6.
C'est marrant, j'avais déjà fait la même il y a trois ans pour mon premier SSD, et j'ai réitéré l'opération il y a six mois pour un autre, et ça marche effectivement très bien. Sauf que j'ai rendu l'opération encore plus transparente : je fais une hibernation / suspend-to-disk avant d'ajouter le SSD. Comme ça, le disque est vu comme ajouté « dynamiquement ». Du coup, moins système n'a même pas vraiment redémarré, et est pourtant passé d'un disque a l'autre…!
# LVM - Linux vs LVM - AIX
Posté par Dabowl_75 . Évalué à 1. Dernière modification le 03 janvier 2014 à 10:19.
Merci pour
cet articlece journal.Je suis étonné tout de même de voir qu'en 2014, on serre encore les fesses ou se félicite de pouvoir migrer à chaud un système d'un disque à un autre avec LVM.
Si je prends à titre de comparaison l'unix proprio de big blue, on pratique ce genre d'opération depuis au moins 15 ans, et sur une grande variété de sous-système de stockage (SAN).
Bref Linux est aussi prêt pour le desktop que pour le serveur :-)
http://www.wmduszyk.com/?p=10340&langswitch_lang=en
[^] # Re: LVM - Linux vs LVM - AIX
Posté par barmic . Évalué à 8.
Je pense que la technique est prête mais qu'elle reste relativement peut utilisé par habitude, manque d'utilité (présumée), peur de ne pas maitriser la bête, etc
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: LVM - Linux vs LVM - AIX
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
AIX fait ça sur archi PC ? ou sur les hardwares uniquement IBM ? Le genre qui contient l'équivalent d'un kvm en hardware ?
"La première sécurité est la liberté"
[^] # Re: LVM - Linux vs LVM - AIX
Posté par Christophe B. (site web personnel) . Évalué à 1.
AIX ne tourne que sur les machines POWER IBM
[^] # Re: LVM - Linux vs LVM - AIX
Posté par Christophe B. (site web personnel) . Évalué à 1.
Aaaah mksysb, nim, et le lvm AIX (et j'en oublie …) que du bonheur.
c'est vrai que linux a encore un peu de chemin à faire pour arriver au même niveau, mais bon il s'agit "d'un long chemin vers la liberté" …
et sinon Bonne Année les moules, la santé et du bonheur \o/
# fstab, UUID et LVM snapshot: attention!
Posté par Bertrand Mathieu . Évalué à 1.
L'UUID dans fstab c'est génial bien, mais attention avec LVM!
J'ai eu une mauvaise surprise en jouant avec la fonction snapshot (sur le home): il y a du coup 2 systèmes de fichiers avec le même UUID. Là où ça se corse, c'est quand le système monte l'un ou l'autre alternativement, y compris en sortant de veille (et oui, on peut écrire sur un snapshot). On peut modifier l'uuid du snapshot, mais dans ce cas il vaut mieux éviter de reverser celui-ci dans le LV d'origine (snapshot merge), puisqu'on perdra l'uuid d'origine.
Bref, tout ça pour dire que pour une partition LVM il est tout aussi simple et stable d'indiquer le chemin "/dev/mapper/Aurora_VG-Home" plutôt que l'uuid, ce chemin ne devrait pas changer sauf si on s'amuse à renommer le VG ou le LV. (il doit aussi exister un alias du genre "/dev/lvm/Aurora/Home")
Dans les montages amusants il aurait été possible d'ajouter le SSD au volume RAID 1, éventuellement retirer l'un des disques durs du RAID, et de déclarer le disque restant dans la raid "write-mostly", mais il n'aurait pas été possible d'étendre le fs (ou alors le raid ne sert plus à rien puisqu'il ne contient pas toutes les données).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.