Lorsque j'ai monté ma machine, je l'ai équipé immédiatement d'un SSD. Je comptais y installer une distribution GNU/Linux. Or, vu la nature des SSD, j'avais compris qu'il existait quelques précautions à prendre mais sans avoir réellement compris. Faute de temps. j'ai laissé de côté, temporairement, ce SSD et j'ai monté mon système principal sur un disque classique. Un an après (environ), il serait temps d'utiliser ce SSD.
Sauf que, au moment de réaliser une image de la partition SDA2 de sécurité avec Acronis True Image 2012, Acronis refuse. A priori, il existe un ou plusieurs clusters à problème, même si la distribution fonctionne à merveille. J'ai réussi à faire mon image de partition autrement. PartImage n'ayant rien voulu savoir (lui aussi), je me suis rabattu vers la ligne de commande (voir cette note). La création de l'image de partition en ligne de commande semble avoir fonctionné sachant que je n'ai pas osé prendre le risque de vérifier en la réinjectant.
De toute manière, selon True Image et PartImage, cette partition a un problème quelque part. Problème qui n'a jamais été détecté, donc corrigé, lors des séquences de 20 démarrage de partitions. Peut-être que je devrais formater pour solutionner ?
L'installation se déroule comme n'importe quelle autre installation. Voici les caractéristiques propres à GNU/Linux sur SSD :
* système de fichiers / : Ext4 ou Btfs
* aligner les partitions
* changer le disk scheduler du noyau
* activer le TRIM
* diminuer la fréquence d'écriture sur SSD
Je me suis basé sur l'excellente documentation Fedora : http://doc.fedora-fr.org/wiki/Les_SSD_sous_fedora
Voici le résumé d'installation :
* Système de fichiers / : Ext4
* SDB1 = / (SSD)
* SDC1 = /home (partition déjà opérationnelle), (disque à plateaux)
* La partition home est la même pour les 2 ou 3 distributions avec des noms utilisateurs différents selon les distributions.
* SDA9 = swap (disque à plateaux)
Le SSD étant de petite taille (64 Go), je n'ai pas jugé utile de le partitionner, même si j'admet volontiers qu'un tel volume peut contenir 2, voire 3, distributions GNU/Linux. De fait, j'ai des difficultés à comprendre le partitionnement des SSD. J'imagine (à tort ?) que les partitions vont plus ou moins se balader dans le SSD selon les cycles d'écritures. Par voie de conséquence, je crains que cela devienne un joyeux bordel.
Par acquis de conscience, et pour mieux comprendre, j'ai cependant vérifier l'alignement. Soit :
# fdisk -lu /dev/sdb
Disque /dev/sdb : 64.0 Go, 64023257088 octets, 125045424 secteurs
Unités = secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xce21ec5b
Périphérique Amorçage Début Fin Blocs Id. Système
/dev/sdb1 * 2048 125033894 62515923+ 83 Linux
La partition débute en 2048 et il n'en existe pas d'autre sur ce SSD. Tout est correctement aligné.
En général, donc sur les disques à plateaux, les données sont pré-traitées, par le disk scheduler, pour être lues et écrites dans des zones géographiquement proches, dans le but d'améliorer les performances. Mais les SSD ne comportent pas de telles zones puisque tout est contenu dans des puces mémoires. D'où la nécessité de désactiver le disk scheduler.
J'ai donc éditer le fichier /etc/rc.d/rc.local afin d'ajouter à la fin du fichiers :
echo 'noop' > /sys/block/sda/queue/scheduler
Le TRIM, qui n'existe pas sur les disques à plateaux, permet de repérer quels blocs sont libres pour une écriture.
Il faut éditer le fichier /etc/fstab afin d'ajouter à toute ligne concernant le SSD certaines informations :
* Pour le système de fichiers ext4 : ajout après defaults, de l'option discard séparée par une virgule et sans espace
* Pour le système de fichiers btrfs : ajout après defaults, des options discard et ssd séparées par une virgule et sans espace
Dans mon cas, cela donne :
/dev/sdb1 / ext4 defaults,discard 0 1
Ceci est propre au format ext4. Cette journalisation permet de reconstruire les données abîmées mais entraîne aussi une augmentation du nombre d'écritures. Pas forcement bon pour un SSD.
Pour désactiver cette journalisation, il faut éditer le fichier /etc/fstab afin d'ajouter l'option noatime, ce qui donne :
/dev/sdb1 / ext4 defaults,noatime,discard 0 1
Notez que ceci est cependant optionnel.
Certains choisissent de placer en mémoire vive les fichiers temporaires. Ainsi, en limitant à 1 Go la taille de ces fichiers temporaires, cela donne :
tmpfs /tmp tmpfs defaults,size=1g 0 0
Ligne à ajouter au fichier /etc/fstab.
On peut également placer en mémoire vive les fichiers journaux en ajoutant au fichier /etc/fstab la ligne suivante :
ram /var/log tmpfs defaults,nosuid,nodev 0 0
Cependant, dans certains cas, ce choix peux être source d'ennuis. En effet, en cas de crash, comment connaître l'origine du problème sans fichiers journaux puisque ces fichiers placés en mémoire RAM disparaissent à chaque redémarrage ? Un choix à faire !
Il existe au moins deux autres possibilités :
* l'utilisation du Swap : utiliser à outrance la mémoire vive pour éviter d'écrire dans la partition Swap.
Il faut éditer le fichier /etc/sysctl.conf pour ajouter en bas de page vm.swappiness = 0
* fichier cache de Firefox : le cache est placé en mémoire RAM mais la machine doit avoir au minimum 2 Go de RAM.
Il faut :
a) taper dans la barre d'adresse about:config
b) entrer comme filtre : browser.cache.disk.enable
c) entrer dans la ligne affichée la valeur false en double-cliqaunt dessus
d) créer une nouvelle chaîne de caractères
e) ayant comme nom browser.cache.memory.enable
f) avec la valeur true
g) créer une nouvelle chaîne de caractères
h) ayant comme nom browser.cache.memory.capacity
i) avec la valeur 200000
La première chaîne de caractère créée désactive le cache sur le SSD tandis que la seconde l'active en mémoire RAM avec, ici, une taille de 200 Mio.
Pour autant, le SSD ne contient que le système (/) et aucunement les données. De ce fait, je n'ai pas eu à faire l'effort avec les fichiers caches importants (Firefox, Chromium, Gimp, LibreOffice) puisqu'ils sont sur le disque à plateaux où se situe la partition /home.
Je n'ai pas non plus délocalisé en mémoire vive les fichiers temporaires et les fichiers journaux. Je verrai à l'usage.
Sources :
https://wiki.archlinux.org/index.php/Solid_State_Drives
http://doc.fedora-fr.org/wiki/Les_SSD_sous_fedora
http://doc.ubuntu-fr.org/ssd_solid_state_drive
1- Pourquoi : De Mageia 2 (SDA2) à Mageia 3 (SDB1)
Jusqu'à présent, mon système d'exploitation principal, c'était Mageia 2 installé sur SDA2, un disque à plateaux. Puis Mageia est sorti dans sa version 3 stable et, d'après la documentation en ligne, il semble assez facile de migrer d'une version N vers N+1 via le réseau. Sauf que ... !Sauf que, au moment de réaliser une image de la partition SDA2 de sécurité avec Acronis True Image 2012, Acronis refuse. A priori, il existe un ou plusieurs clusters à problème, même si la distribution fonctionne à merveille. J'ai réussi à faire mon image de partition autrement. PartImage n'ayant rien voulu savoir (lui aussi), je me suis rabattu vers la ligne de commande (voir cette note). La création de l'image de partition en ligne de commande semble avoir fonctionné sachant que je n'ai pas osé prendre le risque de vérifier en la réinjectant.
De toute manière, selon True Image et PartImage, cette partition a un problème quelque part. Problème qui n'a jamais été détecté, donc corrigé, lors des séquences de 20 démarrage de partitions. Peut-être que je devrais formater pour solutionner ?
2- Installation de Mageia 3 (SDB1) sur SSD
Voilà donc un excellent motif pour installer une distribution sur ce SSD. A l'avoir ! Je me suis préalablement renseigné.L'installation se déroule comme n'importe quelle autre installation. Voici les caractéristiques propres à GNU/Linux sur SSD :
* système de fichiers / : Ext4 ou Btfs
* aligner les partitions
* changer le disk scheduler du noyau
* activer le TRIM
* diminuer la fréquence d'écriture sur SSD
Je me suis basé sur l'excellente documentation Fedora : http://doc.fedora-fr.org/wiki/Les_SSD_sous_fedora
2.1 - Résumé d'installation
Voici le résumé d'installation :
* Système de fichiers / : Ext4
* SDB1 = / (SSD)
* SDC1 = /home (partition déjà opérationnelle), (disque à plateaux)
* La partition home est la même pour les 2 ou 3 distributions avec des noms utilisateurs différents selon les distributions.
* SDA9 = swap (disque à plateaux)
2.2 - Alignement des partitions
Le SSD étant de petite taille (64 Go), je n'ai pas jugé utile de le partitionner, même si j'admet volontiers qu'un tel volume peut contenir 2, voire 3, distributions GNU/Linux. De fait, j'ai des difficultés à comprendre le partitionnement des SSD. J'imagine (à tort ?) que les partitions vont plus ou moins se balader dans le SSD selon les cycles d'écritures. Par voie de conséquence, je crains que cela devienne un joyeux bordel.
Par acquis de conscience, et pour mieux comprendre, j'ai cependant vérifier l'alignement. Soit :
# fdisk -lu /dev/sdb
Disque /dev/sdb : 64.0 Go, 64023257088 octets, 125045424 secteurs
Unités = secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xce21ec5b
Périphérique Amorçage Début Fin Blocs Id. Système
/dev/sdb1 * 2048 125033894 62515923+ 83 Linux
La partition débute en 2048 et il n'en existe pas d'autre sur ce SSD. Tout est correctement aligné.
2.3 - Changement du disk scheduler
En général, donc sur les disques à plateaux, les données sont pré-traitées, par le disk scheduler, pour être lues et écrites dans des zones géographiquement proches, dans le but d'améliorer les performances. Mais les SSD ne comportent pas de telles zones puisque tout est contenu dans des puces mémoires. D'où la nécessité de désactiver le disk scheduler.
J'ai donc éditer le fichier /etc/rc.d/rc.local afin d'ajouter à la fin du fichiers :
echo 'noop' > /sys/block/sda/queue/scheduler
2.4 - Activation du TRIM
Le TRIM, qui n'existe pas sur les disques à plateaux, permet de repérer quels blocs sont libres pour une écriture.
Il faut éditer le fichier /etc/fstab afin d'ajouter à toute ligne concernant le SSD certaines informations :
* Pour le système de fichiers ext4 : ajout après defaults, de l'option discard séparée par une virgule et sans espace
* Pour le système de fichiers btrfs : ajout après defaults, des options discard et ssd séparées par une virgule et sans espace
Dans mon cas, cela donne :
/dev/sdb1 / ext4 defaults,discard 0 1
2.5 - Désactivation de la journalisation des dates de lecture des fichiers
Ceci est propre au format ext4. Cette journalisation permet de reconstruire les données abîmées mais entraîne aussi une augmentation du nombre d'écritures. Pas forcement bon pour un SSD.
Pour désactiver cette journalisation, il faut éditer le fichier /etc/fstab afin d'ajouter l'option noatime, ce qui donne :
/dev/sdb1 / ext4 defaults,noatime,discard 0 1
Notez que ceci est cependant optionnel.
2.6 - Placer les fichiers temporaires en mémoire vive
Certains choisissent de placer en mémoire vive les fichiers temporaires. Ainsi, en limitant à 1 Go la taille de ces fichiers temporaires, cela donne :
tmpfs /tmp tmpfs defaults,size=1g 0 0
Ligne à ajouter au fichier /etc/fstab.
2.7 - Placer /var/log en mémoire vive
On peut également placer en mémoire vive les fichiers journaux en ajoutant au fichier /etc/fstab la ligne suivante :
ram /var/log tmpfs defaults,nosuid,nodev 0 0
Cependant, dans certains cas, ce choix peux être source d'ennuis. En effet, en cas de crash, comment connaître l'origine du problème sans fichiers journaux puisque ces fichiers placés en mémoire RAM disparaissent à chaque redémarrage ? Un choix à faire !
2.8 - Autres pistes
Il existe au moins deux autres possibilités :
* l'utilisation du Swap : utiliser à outrance la mémoire vive pour éviter d'écrire dans la partition Swap.
Il faut éditer le fichier /etc/sysctl.conf pour ajouter en bas de page vm.swappiness = 0
* fichier cache de Firefox : le cache est placé en mémoire RAM mais la machine doit avoir au minimum 2 Go de RAM.
Il faut :
a) taper dans la barre d'adresse about:config
b) entrer comme filtre : browser.cache.disk.enable
c) entrer dans la ligne affichée la valeur false en double-cliqaunt dessus
d) créer une nouvelle chaîne de caractères
e) ayant comme nom browser.cache.memory.enable
f) avec la valeur true
g) créer une nouvelle chaîne de caractères
h) ayant comme nom browser.cache.memory.capacity
i) avec la valeur 200000
La première chaîne de caractère créée désactive le cache sur le SSD tandis que la seconde l'active en mémoire RAM avec, ici, une taille de 200 Mio.
3 - Conclusion
Voilà près de deux mois que j'ai installé Mageia 3 sur le SSD. Sans évoquer la distribution elle même, l'ensemble est parfait, rapide à souhait. J'avoue que j'éprouve des difficultés à mesurer une quelconque différence de vélocité avec celle installée sur VelociRaptor ; bien qu'il soit vrai que je n'ai pas mesuré à l'aide d'outils d'analyse appropriés.Pour autant, le SSD ne contient que le système (/) et aucunement les données. De ce fait, je n'ai pas eu à faire l'effort avec les fichiers caches importants (Firefox, Chromium, Gimp, LibreOffice) puisqu'ils sont sur le disque à plateaux où se situe la partition /home.
Je n'ai pas non plus délocalisé en mémoire vive les fichiers temporaires et les fichiers journaux. Je verrai à l'usage.
Sources :
https://wiki.archlinux.org/index.php/Solid_State_Drives
http://doc.fedora-fr.org/wiki/Les_SSD_sous_fedora
http://doc.ubuntu-fr.org/ssd_solid_state_drive
Commentaires
Enregistrer un commentaire