Je viens de monter un SSD à la place de mon ancien disque classique sur mon macbook vieux de 3 ans. Voici un bref retour d’expérience.
Afin d’avoir quelques chiffres, avant d’installer le SSD, j’ai installé bonnie++ qui est un logiciel de benchmark de disque.
Pour le lancer, voici une commande permettant de prendre en compte facilement la quantité de RAM disponible sur votre PC ( je ne sais plus trop d’où elle vient, merci à son auteur en tout cas 😉
sudo bonnie++ -n 0 -u 0 -r `free -m | grep 'Mem:' | awk '{print $2}'` -s $(echo "scale=0;`free -m | grep 'Mem:' | awk '{print $2}'`*2" | bc -l) -f -b -d /home
Cette commande nous donne un résultat brut assez peu lisible.
Using uid:0, gid:0.
Writing intelligently...done
Rewriting...done
Reading intelligently...done
start 'em...done...done...done...
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
EquinoxeFR 7366M 40652 5 18250 2 61482 4 70.7 0
EquinoxeFR,7366M,,,40652,5,18250,2,,,61482,4,70.7,0,,,,,,,,,,,,,
Heureusement, bonnie++ est fourni avec des scripts permettant de mettre en forme les données.
echo "EquinoxeFR,7366M,,,40652,5,18250,2,,,61482,4,70.7,0,,,,,,,,,,,,," | bon_csv2html > bonnie_results.html
Ce qui nous donne un tableau HTML de ce type.
Maintenant que nous avons les chiffres de notre disque classique, nous pouvons installer le SSD. Afin de faciliter la migration des données, j’ai monté le SSD dans le portable et placé l’ancien DD dans un boitier USB. La copie des partitions existantes a été faite à l’aide de Clonezilla lancé depuis le LiveCD « parted magic« .
Voilà, les données sont copiés, nous redémarrons la machine en à peine 10 sec !!! ( de grub à l’invite de login GDM )
Visiblement le gain de performance est bien là et le silence est absolu, pas une pièce en mouvement, quel plaisir.
Afin d’améliorer encore l’utilisation du SSD, voici quelques optimisations:
Tout d’abord, changeons le « I/O Scheduler » qui est contre productif en mode « cfq » avec un disque SSD. Dans /boot/grub/menu.lst, il faut placer elevator=deadline dans les paramètres du kernel.
# (0) Arch Linux
title Arch Linux
root (hd0,0)
kernel /boot/vmlinuz-linux root=/dev/sda1 elevator=deadline ro quiet vga=773
initrd /boot/initramfs-linux.img
Ce qui après un redémarrage nous donne
[pierre@EquinoxeFR ~]$ cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
[pierre@EquinoxeFR ~]$
Ensuite, réglons quelques paramètres pour le montage de nos partitions:
[pierre@EquinoxeFR ~]$ cat /etc/fstab
#
# /etc/fstab: static file system information
#
#
devpts /dev/pts devpts defaults 0 0
shm /dev/shm tmpfs nodev,nosuid 0 0
/dev/sda1 / ext4 noatime,discard,data=writeback,errors=remount-ro 0 1
/dev/sda2 swap swap defaults 0 0
/dev/sda3 /home ext4 noatime,discard,data=writeback,errors=remount-ro 0 1
- noatime: désactive la mise à jour de l’heure d’accès aux fichiers. Ca n’a que peu d’intérêt et ça use le SSD inutilement.
- discard: active le TRIM pour préserver au maximum la durée de vie du SSD
- data=writeback: journalise uniquement les métadatas avec EXT4. Attention il faut faire un tune2fs -o journal_data_writeback /dev/sda1 depuis un CD bootable sur la partition root sous peine de ne pas pouvoir redémarrer…
Voilà, après ces quelques optimisations, nous avons un système très réactif ( le jour et la nuit 🙂 même si je suis un peu étonné que les chiffres ne soit pas plus parlants. J’ai un SSD SATA III alors que mon portable ne supporte que le SATA II mais qui peut le plus, peut le moins… Ceci dit, j’ai quand même l’impression d’avoir des résultats en dessous de ce que l’on peut trouver sur le net. Peut-être que ça vient du contrôleur du macbook… sur OSX, beaucoup ont des problèmes de « link speed » sur le bus SATA avec de nombreux SSD.
Update 5/02:
Les résultats avec le scheduleur sur noop
nouveaux résultats avec AHCI Mode = SATA
J’ai mis à jour ArchWiki pour l’activition du mode SATA sur un macbook 5.1
