Bienvenue sur le topic des SSD sous Linux

Ce topic se veut le plus complet possible en ce qui concerne l'utilisation des SSD sous Linux. En effet, si on trouve de nombreuses informations concernant l'utilisation et la configuration des SSD sous Windows, les même informations appliquées à Linux sont plus rares et plus difficiles à dénicher. Ainsi, ce topic se chargera de compiler toutes les informations glanées sur le net ou issues de l'expérience des utilisateurs d'HFR de SSD sous Linux.

Sommaire
I. Généralités sur les SSD
II. Installer sa distribution sur un SSD
III. Conseils et astuces pour optimiser son SSD
IV. Recensement des utilisateurs de SSD sous Linux

I. Généralités sur les SSD

• Présentation de la technologie SSD

Les SSD (pour Solid State Drive) représentent les unités de stockages destinées à remplacer nos traditionnels disques durs (HDD pour Hard Disk Drive). Ils sont basés sur la mémoire Flash en lieu et place des plateaux magnétiques. C'est dans les cellules des puces de mémoire Flash que l'on lit et écrit les données. Afin de réaliser ces opérations, un contrôleur dédié intégré au SSD reçoit les requêtes et les traite, épaulé ou non suivant les modèles par de la mémoire cache.

Les avantages de cette technologie sont :
     - l'inexistence d'usure mécanique puisqu'aucune pièce n'est en mouvement, ce qui induit l'insensibilité (relative certes) aux chocs et un total silence de fonctionnement;
     - des débits au dessus des meilleurs HDD, surtout pour les dernières génération de SSD qui accrochent les 220 Mo/s en lecture séquentielle, et flirtent avec les 200 Mo/s en écriture séquentielle (on est proche du Go/s pour les SSD professionnels sur carte PCI-Express, à des prix complètement indécents , voir ici). Ces débits sont nettement inférieurs en lecture ou écriture aléatoire, mais toujours nettement au dessus des débits dans les même conditions des HDD;
     - des temps d'accès nettement inférieur à ceux des HDD, puisqu'on parle généralement de temps compris entre 0.2 et 0.1 ms, voir moins, là où les HDD se situe entre 5 ms (15000 trs/min SAS) et 15 ms (7200 trs/min SATA);
     - une consommation électrique inférieure environ de moitié par rapport aux HDD, même si les HDD 2"1/2 sont proches des consommation des SSD, avec à la clé un dégagement thermique inférieur;
     - l'insensibilité à la fragmentation des système de fichiers puisque, contrairement aux HDD, il n'est pas nécessaire d'attendre une mécanique lente pour accéder à deux informations situés à des emplacements physiquement éloignés sur le SSD (comprendre dans des puces mémoires différentes par exemple);

Néanmoins, les SSD n'ont pas que des avantages, et on peut leur reprocher :
     - une durée de vie limitée par le nombre de cycles lecture/écriture auxquels sont soumises les puces mémoire, même si des mécanismes de minimisation de l'usure sont mis en place au niveau des contrôleurs sur les SSD (wear levelling);
     - des capacités des stockage plus faibles que celles des HDD, même si cela tend petit à petit à s'améliorer;
     - un prix au Go largement plus élevé que celui des HDD, ce qui signifie qu'à capacité égale, un SSD coutera beaucoup plus cher qu'un HDD;

• Caractéristiques essentielles d'un SSD

Comme toute technologie, les SSD connaissent un phénomène de gamme qui les place sur une échelle, aussi bien en terme de prix qu'en terme de performances, les deux étant souvent liés. Ainsi, pour choisir son SSD, on pourra se fier au caractéristiques suivantes :
     - le type de cellules mémoire utilisées : on distingue deux types de cellules Flash dans les SSD : les SLC (Single Level Cell) et les MLC (Multi Level Cell). En résumé, les puces SLC sont plus rapides, ont une meilleure durée de vie mais sont également beaucoup plus chères et ont des capacité de stockage inférieur aux MLC. Ainsi, les SLC seront réservées aux SSD très haut de gamme et souvent de faible capacité, là où les SSD abordables et de capacité importante seront systématiquement basés sur des puces MLC;
     - le contrôleur : c'est une pièce maitresse d'un SSD, dans le sens ou un contrôleur de mauvaise qualité ne permettra pas de restituer les performances que les puces Flash peuvent offrir. C'est ce qui s'est passé sur les premières générations de SSD basé sur des contrôleurs JMicron JM601 ou JM602, qui sont à éviter absolument. Les contrôleur Indilinx, Intel ou Samsung offrent quand à eux des performances stables et satisfaisantes;
     - le support du TRIM : le TRIM est une technologie permettant d'améliorer les performances dans le temps des SSD. En effet, en raison de leur principe de fonctionnement, les SSD ont tendances à voir leurs performances baisser au fur et à mesure qu'on les utilise. Le TRIM tend à réduire, voir à supprimer, cette baisse de performance. Pour plus de précision, le principe de fonctionnement des SSD et du TRIM est expliqué dans cet article. Le TRIM doit être supporté par le SSD mais également par l'OS. Les SSD à base de chipset Indilinx ou SandForce ainsi que les SSD Intel supportent le TRIM. Le noyau 2.6.33 permet d'appliquer le TRIM à la volée avec ext4, moyennant un montage des partitions accompagné de l'option discard. Pour les autres cas (ext3, kernel antérieur au 2.6.33), il faudra passer par un script manuel qui permet de trimmer ses partitions une à une. Ce script est disponible ici;

• Vocabulaire de la technologie SSD

    - alignement des partitions : même si l'alignement des partitions n'est pas spécifiques aux SSD, il n'a que très peu d'importance sur un spinoff, sauf dans le cas des volumes RAID5. L'alignement consiste à faire correspondre les blocs logiques des partitions avec les blocs physiques du SSD pour améliorer les performances de celui-ci afin de limiter les opérations de lecture et d'écriture. L'alignement des partitions fait l'objet d'un paragraphe à part dans la section suivante.
     - wear-levelling : c'est une technique utilisé par les contrôleurs des SSD. Elle consiste à répartir l'usure des puces mémoires en écrivant le moins souvent possible dans les même cellules, et en profitant ainsi au maximum du nombre de cycles de lecture/écriture de chacune des cellules. De ce fait, avec un bon algorithme de wear-levelling, on arrive à faire en sorte qu'un SSD ait une durée de vie de l'ordre de plusieurs années.
     - garbage collector : dixit HFR himself, c'est un mécanisme visant à réorganiser la table d’allocation à la volée, ce qui permet de conserver un bon niveau lors d’écritures séquentielles sur une zone précédemment écrite de manière aléatoire. Avantage : on récupère les performances d'origine du SSD en écriture séquentielle ou presque. Inconvénient : on génère de nombreuses écritures dans les puces mémoire, ce qui a tendance à amoindrir la durée de vie du SSD, et le disque travaillant en interne, il ne libère pas les pages de Flash comme le fait le TRIM, ce qui fait que cela n'a n'est efficace que pour les écritures séquentielles, sans améliorer les écritures aléatoires. Plus de précisions dans cet article. Tous les SSD semblent utiliser ce procéder, de manière plus ou moins agressive, et ce à la volée ou en tâche (on parle alors de background garbage collection) de fond en fonction de l'objectif du fabricant.

Pour en savoir plus, je vous propose la lecture de cet article, plutôt bien fait (en anglais malheureusement) :
http://arstechnica.com/information [...] ally-work/

II. Installer sa distribution sur un SSD

/!\ Attention, cette méthode ne vaut que pour les versions antérieures à la 2.2 de parted. Au delà, parted réalise automatiquement un alignement sur 2048 secteur, ce qui est parfait pour tous les SSD, sans avoir à calculer quoi que ce soit. Il est ainsi à nouveau possible de partitionner simplement, en utilisant le Mo ou le Go comme unité. La création des système de fichier reste en revanche d'actualité.

• Partitionner son SSD - Méthode avec table de partitions classique

Cette méthode semble donner de bons résultats. Elle repose principalement sur les recherches de [albator] que je remercie chaleureusement pour nous avoir fait profiter de ses résultats. J'ai moi-même repris cette méthode pour partitionner et formater mes partitions, avec succès.

J'ai démarré l'installeur de Arch depuis ma clé USB. Pour une autre distribution, il faudra démarrer une session Live ou utiliser un CD spécifique comme Ultimate Boot CD ou quelque chose d'équivalent. Une fois connecté, en console, je me suis servi de parted. Je me retrouve donc sur l'invite de parted, première vérification : la version du SSD :

La version du SSD en 1.10, c'est parfait, c'est la dernière version disponible, pas besoin de flasher le firmware.
La taille d'un bloc, étant de 128 Ko, et un secteur représentant 512 o, on en déduit que chaque bloc est composé de 256 secteurs (128 Ko / 512 o). On va donc aligner les partitions en comptant le nombre de secteur, de manière à ce que chaque début de partition tombe sur un multiple de 256, soit un début de bloc. D'autre part, afin de tenir compte du premier secteur réservé on va volontairement décaler la première partition jusqu'au premier secteur multiple de 256. Cela ne gâche que quelques Ko et permet de rester aligné quoi qu'il arrive.
Commençons par déterminer quel est le dernier secteur du SSD, en changeant d'abord l'unité utilisée pour afficher les informations du SSD (l'unité devient le secteur) :

A l'aide d'un petit tableau sous Calc (que vous pouvez télécharger ici), j'ai calculé, à partir de la taille souhaitée de mes partitions, le secteur de début et de fin de chacune de mes partitions en suivant la règle suivante :
Taille de la partition en secteurs = taille de la partition en Mo * 1024 * 1024 / 512
Une partition est donc définie par son secteur de début et son secteur de fin, ce dernier étant le secteur de début + la taille de la partition en secteur - 1 (on retranche 1 pour tenir compte du secteur du début). La partition suivante commence au secteur suivant qui sera forcément, grâce à la méthode de calcul, un multiple de 256.
Du coup, j'en ai déduis le tableau suivant :

Du coup, dans parted, il devient très simple de créer ses partitions à partir des infos calculées :

On peut vérifier le résultat une fois les partitions créées :

Si on affiche à nouveau les informations avec l'octet comme unité, on peut vérifier la taille des partitions de manière plus parlante :

Il ne reste plus qu'à placer le drapeau de boot sur la première partition pour s'assurer du bon fonctionnement du bootloader et du chargement du futur OS:

Le résultat en vérification :

Il faut maintenant créer les système de fichiers. De mon côté, je passe par ext4, que je monterai ensuite avec l'option noatime pour ne pas provoquer d'écriture lors d'une simple lecture. Là encore, on se sert des options de formatage du système de fichiers ext4 pour aligner la partition. Il faut aligner la partition avec des blocs logique de 4 Ko (4096 o), et un stride respectant l'alignement des blocs physique du SSD. Les blocs logiques font 4 Ko, on sait que les blocs physique font 128 Ko, on aura donc un stride de 32 (128 Ko / 4 Ko). J'avoue ne pas trop comprendre cette histoire de stride, mais l'utilisation de ces deux valeurs permet visiblement de tout aligner correctement. On créé donc les systèmes de fichiers ext4 sur les partitions adéquat :

Si vous souhaitez utiliser ReiserFS, il est possible de formater vos partitions en foçant  la taille des blocs logique, mais pas le stride. Ne sachant pas quelle est l'influence de ce paramètre, je ne sais pas si cela va réellement dégrader les performances ou pas, mais a priori, cela reste négligeable voir même inexistant :

Si quelqu'un sait comment forcer ces paramètres sur la partition de swap, je suis preneur. Même si au final je ne monte pas cette partition, ArchLinux impose d'avoir une partition de swap au moment de l'installation, donc autant que cette dernière soit également alignée.
Ensuite, lors de l'installation, on définit les point de montage, mais on ne les formate pas. Il le sont déjà, et un nouveau formatage ne réutiliserait pas forcément les valeurs de bloc et de stride que l'on a utilisé, ruinant alors l'alignement.
Pour terminer, une fois la distrib installée, j'ai placé, comme indiqué dans les astuces plus bas, le /tmp en tmpfs, désactivé le montage de la partition swap dans fstab, désactivé le démon de log et monté les partitions ext4 avec l'option noatime.

• Partitionner son SSD - Méthode avec table de partitions GPT

Là encore, un grand merci à [Albator], décidemment, sans lui, ce topic n'aurait pas la même physionomie

Avec cette méthode, on ne change que la façon de compter les partitions, mais pas celle de compter les blocs. Ainsi, on gardera les même partitions que dans la méthode précédente, avec les même secteurs de début et de fin, mais on utilise une autre façon de créer les partitions. Je vous conseille donc de lire la méthode précédente avant de vous lancer dans celle-ci qui en reprend les grands principes.
Le problème de la méthode précédente est qu'elle se limite à 4 partitions, puis que les tables de partitions stanbards se limitent à 4 partitions primaires. Une autre solution consisterait à ne créer qu'une partition étendue sur l'intégralité du disque dur, et de tailler ses lecteurs logiques dedans. Néanmoins, il existe une autre façon de créer ses partition : utiliser une table de partition de type GPT. Avec ce type de table, qu'on pourrait qualifier de "moderne", la nuance entre partition principale et étendue n'existe plus, toute les partitions étant du même type, et il n'y a plus de limite au nombre de partitions que l'on peut créer sur un disque.
Ce qu'il faut savoir avant de se jeter sur cette méthode, qui semble mettre tout le monde d'accord de prime abord :
- les partitions référencées dans une table GPT sont accessibles sous Windows comme sous Linux, mais a priori, seul Linux saura booter dessus via GRUB. Du coup, pas de multiboot Windows Linux avec cette méthode.
- les partitions référencées dans une table GPT portent forcément un label, ainsi il est préférable de savoir ce qu'on va mettre sur ses partitions avant de se lancer dans le partitionnement afin de donner aux partitions des labels cohérents.
- la création d'une table GPT efface l'intégralité du disque, donc on utise cette méthode lorsqu'on a un disque neuf ou après un gros backup de toutes ses données.

Ceci mis au clair, on peut partitionner le disque, toujours avec Parted. Pour cela, une fois parted lancé, on commence par créer la table GTP (c'est à ce moment que toutes les partitions antérieures et les données qu'elles contenaient deviendront innaccessibles) :

On change l'unité de parted pour le secteur :

Ensuite, on créé les partitions en utilisant les secteurs trouvés par les calculs de la méthode précédente, en donnant à chaque partition le label qui correspond au type de données qu'elles vont recevoir :

Les partitions créées, on reprendra la méthode précédente pour la création des systèmes de fichiers, les règles sur la taille de bloc et de stride pour les volumes ext4 semblant toujours d'actualité avec ce type de partitionnement.

• Choix du système de fichiers

Le choix du système de fichiers pour un SSD est problématique. En effet, comme on l'a dit précédemment, on cherche à éviter au maximum les écritures inutiles sur un SSD pour en préserver au maximum la durée de vie. Dans le même temps, les systèmes de fichiers modernes sont tous journalisés, c'est à dire qu'ils stockent de nombreuses informations sur les accès aux fichiers, ce qui génère de nombreuses écritures mais garantie également dans une certaine mesure la sécurité des données en cas de crash du système. On se trouve donc devant un conflit d'intérêt.

    - utilisation des système de fichiers optimisés pour les stockage sur Flash : on compte parmi ces système de fichiers JFFS2, LogFS ou UBIFS. Ils incorporent des optimisations permettant de limiter les entrées/sorties, et pour certains de journaliser. En revanche, il s'avère que dans le cas des SSD, ils ne sont pas spécialement adaptés car les SSD intègre désormais au niveau du contrôleur des algorithme effectuant déjà les optimisation susceptibles d'être utiles dans ces systèmes de fichiers. Le travail serait donc réalisé deux fois, ce qui est inutile. Pire, cela induirait dans certains cas des latences qui peuvent ralentir le système. En attendant BTRFS, ces systèmes de fichiers sont donc à exclure pour l'utilisation d'un SSD.

    - utilisation d'un système de fichier non journalisé :la première solution consiste à utiliser un système de fichiers non journalisé, c'est à dire concrètement ext2. Ce système de fichiers ne génère pas d'écriture particulière en dehors des sauvegardes de données explicites. Il aura donc tendance à économiser un SSD. Néanmoins, le risque de perte de donnnées en cas de crash est réel, et il faut donc l'utiliser en connaissance de cause.

    - utilisation des systèmes de fichiers journalisés : comme dis plus tôt, le principal intérêt des systèmes de fichiers journalisés est de garantir une (relative) sécurité des données en cas de crash du système ou d'extinction brutale de la machine. La journalisation entrant en conflit avec la durée de vie des SSD, il est difficile de faire un choix. Néanmoins, ce qui ressort des discussions sur le net et des déclarations des constructeurs autant que des sites spécialisés est que le wear-levelling permet de s'affranchir de ce problème, en gérant directement au niveau du contrôleur l'usure des puces mémoire. L'utilisation des systèmes de fichiers ext3, ext4 ou ReiserFS est envisageable sur les SSD assez récent, qui incorporent une bonne gestion du wear-levelling. On pourra néanmoins améliorer la gestion de la journalisation en se servant des options de montage des partitions journalisées, comme on le verra dans la partie III. A noter néanmoins que ext4 est l'étape précédent BTRFS, système de fichiers qui devrait inclure des optimisation spéciales pour les SSD. On peut donc imaginer que ext4 incorpore déjà une partie de ces optimisations, et qu'il est préférable à ext3 dans le cadre de l'utilisation d'un système de fichiers journalisé sur un SSD. Pour finir, on soulignera que seul ext4 supporte le TRIM à la volée pour les SSD qui le permettent (voir le paragraphe sur le TRIM dans le premier post).

III. Conseils et astuces pour optimiser son SSD

Au fil des discussions sur ce topic, voici une petite compilation des conseils et astuces permettant de tirer parti au mieux de son SSD ou d'en prendre le plus grand soin, notamment en ce qui concerne sa durée de vie.

• Supprimer le swap

Cette astuce ne s'adresse qu'à ceux dont la machine dispose d'au moins 1 Go de RAM. Il est possible dans ce cas, et suivant l'utilisation que l'on fait de la machine de ne pas se servir de swap. Pour cela, soit on ne créé aucune partition de swap lors de l'installation de la distribution, soit, dans le fichier /etc/fstab, on commente la ligne montant le fichier swap :

devient alors :

Il peut être préférable d'utiliser la méthode consistant à ne pas monter une partition de swpa existante, de manière à pouvoir la réactiver facilement en cas de besoin, l'utilisation du swap pouvant varier en fonction de l'utilisation de la machine.

• Désactiver le logging

La plupart des démons logguent leurs activités. Or il est finalement assez rare d'aller consulter ces fichiers de log, car tant que la machine fonctionne correctement, il n'y a pas de raison de les lire pour le plaisir. Du coup, on peut tout simplement désactiver le démon permettant le logging. Ce démon, syslog, est démarré par le système au boot de la machine. Ainsi, en focntion de votre distribution, il faudra désactiver le lancement de ce démon.
Sous Arch, on pourra préfixer le démon syslog-ng d'un point d'exclamation pour en empêcher le démarrage.

Comme pour le swap, il est préférable de désactiver le lancement du démon plutôt que de le supprimer purement et simplement, son utilisation pouvant être nécessaire en cas de problème.

• Modifier les paramètres de journalisation

Par défaut, une partition en ext3 ou ext4 journalise non seulement les opérations d'écriture (ctime, l'heure de création, et mtime, l'heure de la dernière modification) mais également les opérations de lecture (atime l'heure du dernier accès), ce qui génère une écriture à chaque lecture. Dans le cas d'un SSD, c'est particulièrement problématique si on souhaite économiser la durée de vie de ce dernier. C'est pourquoi, on peut désactiver la journalisation de lecture lors du montage des partitions, dans le fichier /etc/fstab en ajoutant le paramètre noatime pour chacune des partitions ext3 ou ext4 hébergée sur le SSD :

Pour ceux qui souhaitent utiliser ReiserFS de la même manière, c'est possible, avec la commande suivante :

• Activer le TRIM à la volée

Si on dispose d'un SSD supportant le TRIM, qu'on utilise une distribution proposant au moins le kernel 2.6.33 et que l'on utilise ext4 comme système de fichier, on peut alors profiter des fonctions TRIM en temps réel et sans avoir à exécuter un script. Pour cela, il suffit d'ajouter l'option discard dans la ligne de montage des partitions concernées :

Attention : l'activation du TRIM peut provoquer des pertes de performances dans certains cas, retirez discard si vous constatez des baisses de performances et tournez vous vers un TRIM manuel régulier à l'aide du script Wiper.

• Placer la dossier temporaire en RamDisk

Afin de limiter les accès au SSD et ainsi éviter les lectures/écritures inutiles, il est intéressant de placer le dossier temporaire en RAM plutôt que sur le disque dur. En plus d'accéler quelques traitements, cette méthode à également l'avantage de vider ce dossier à chaque boot. Pour ce faire, dans /etc/fstab, on ajoutera la ligne suivante :

Il peut également être intéressant, pour ceux qui laissent leur machine allumée 24h/24, de placer une règle cron qui vide les fichiers temporaires à intervalle régulier, afin de ne pas encombrer la mémoire. La commande à mettre dans la tâche cron est la suivante :

Merci à Dek et au forum Gentoo francophone pour ces astuces

• Placer la partie "vivante" de FireFox en RamDisk

Cette astuce fonctionne indépendamment de la précédente, mais mise en place conjointement, elle se complètent parfaitement. Il s'agit ici de limiter les accès au SSD par FireFox, sans pour autant perdre tout son profil à chaque boot. Ainsi, on aura besoin de rsync pour réaliser les synchronisation de données. Avec FireFox fermé, on commence par dupliquer .mozilla dans un second dossier qui servira de sauvegarde lorsque la machine sera éteinte et de source de restauration lorsque la machine sera allumée :

On monte en RamDisk le répertoire du profil FireFox :

Ou on remplacera dans le chemin kortex par le nom de votre utilisateur, et où on s'assurera que les valeurs de uid et gid correspondent à celle de l'utilisateur et de son groupe principal.
Ensuite, dans les scripts s'exécutant au démarrage et à l'extinction de la machine, on synchronise le répertoire de référence (.mozilla_ref) et le répertoire normal (.mozilla). A l'allumage de la machine :

A l'extinction de la machine :

Dans mon cas, sous Arch, les fichiers à modifier sont /etc/rc.local et /etc/rc.local.shutdown, il faudra trouver ceux qui correspondent à votre distribution.
Merci à Dek pour cette astuce

IV. Recensement des utilisateurs de SSD sous Linux
 
[albator] : Samsung SLC 32 Go
Aiua : Crucial M225 64 Go
Az4zel : Intel X25-M G2 80 Go
Aznox : Intel X25-M V2 80Go
Azrail : Samsung EVO 850 250 Go, Debian
babajaga888 : Vertex 4 128 Go, Ubuntu
bronislas : Intel X25-V
Burn2 : SSD intel 520, Xubuntu 12.04
cactus : Crucial C300 128 Go
carrion crow : Crucial C300 128Go, Crucial M4 128 Go,  Crucial M500 mSata 240Go, ArchLinux x64
d@kn1ko : Crucial M4 64go, Xubuntu
Deadog : OCZ Vertex Turbo 30 Go
deK : Intel 520 120 Go, ArchLinux
DiamondCorporation : SSD Samsung 840Pro 128 Go, Linux Mint Cinnamon 64 bits
dusty35 : Crucial M4 64 Go, Ubuntu 11.04
eccoh : Samsung 32Go SLC, Corsair X32
Flying-Chewbacca : Samsung P18000, Kingston v300 120 Go + crucial m550 240 Go
free evey : Corsair 120 Go, Crucial M500 128 Go, SanDisk Ultra 128 Go, tout sous Sabayon
frenchieisverige : Intel Cherryville 520, Elementary OS
grao : Crucial C300 64Go sous Ubuntu 11.10, OCZ vertex 4 256 Go sous debian Wheezy
hecube : Samsung SSD 830 Series, Ubuntu
Jadou2291 : Crucial M225 64 Go / Kingston SSDnow V-Series 40 Go / Mtron 3025 16 Go
kikiesttoujoursla : Crucial C300 64go, Debian Squeeze
Kortex@HFR : Crucial M4 512 Go, Debian x86_64
Kytrix : Crucial C300 64 Go, Ubuntu 64Bits
krumli : Intel X25M Postville 160 Go  
La Volte : Samsung 840 Pro 256 go, Archlinux x86_64  
Le Taz : Samsung 840 Pro 256 go, Archlinux x86_64  
lepcfou : Crucial M4 256 Go, Ubuntu  
l0g4n : Silicon Power 32Go
M300A : Transcend TS120GSSD25D-M 120Go
Mac Gyver 974 : Corsair Nova 32 Go, Gentoo
matthias : OCZ Vertex 2 60 Go, Ubuntu 11.04
memaster62 : CF Sandisk 12 et 8 Go
minux : Samsung 840pro 128gb, Crucial M500 120gb, Crucial MX100 512Gb
muzah : Corsair F60
Morpheus86 : Crucial M4 64 Go, ArchLinux x86_64
mqnu : Corsair Vertex 4, SanDisk SDSSDRC032G, Debian testing
Nossyfff :  OCZ Octane 128Go, Xubuntu 12.04 x86_64
opt : OCZ Vertex Turbo 60
Plam : Intel "Postville" X25-M 80 Go
punishthecat : OCZ Solid Series
s@r@v : Crucial M225 64 Go
Sagittarius : OCZ  Solid_SSD 32, Aspire One
sligor : Corsair Force GT 120 Go, Debian
Swiss_Knight : Crucial M4 128Go, Ubuntu
Sylfurd : Toshiba THNSNC128GMMJ 128 Go
Targan82 : Crucial C300, Debian
thana54 : Kingston SSDNow M-Series 40Go, OCZ Octane 128Go, Debian Sid amd64
The_K586 : SSD Asus 16Go
thorens : Crucial M4, Debian testing
TNZ : OCZ Vertex 4 sous Ubuntu 13.04 64 bit (+ Firmware Redmondien V7 pour les jeux)
Vélo Love : Crucial M4 64 Go, OpenSUSE 12.1
whiterabbit : Intel 330 Series 180 Go, ArchLinux x86_64
zelogik : Intel X25-E 64Go et OCZ Core Series V2 120Go

Je commencerai en parlant, d'après ce que j'ai lu des fichiers temporaires.

Apparemment, on peut se permettre, si on dispose de suffisamment de RAM, de mettre /tmp en RAM pour ne pas utiliser inutilement le SSD. Pour cela, on doit passer par la modification de fstab, en ajoutant la ligne suivante :

Du coup, tout ce qui doit transiter par /tmp ne passe plus par le SSD, ce qui évite de l'user.
_____________________________________________________

On conseille régulièrement de ne pas utiliser ext3/ext4 à cause de la journalisation qui a tendance à créer pas mal de traffic, et d'en rester à ext2, non journalisé, pour les SSD.
_____________________________________________________

Que pensez-vous de ces astuces/conseils ? Sont-ils corrects, méritent-ils d'être dans le premier post ?

Concernant la journalisation je me prendrais pas la tête.
 
En ayant lu plein de trucs là-dessus pour le SSD mon Aspire One, les algos de wear-levelling font en sorte que la durée de vie est assez grande, même en écrivant beaucoup sur le disque : je n'ai plus les chiffres en tête, mais c'est du genre 10 ans de durée de vie en écrivant chaque jour sur la moitié du SSD (ce que personne ne fait en utilisation classique).
 
Et la journalisation ben c'est quand même sympa en cas de crash, donc je dirais Ext3 ou Ext4, c'est vraiment sans risque.
(Ext4 je nuance un peu maintenant, j'ai été victime du symptôme des fichiers à 0 octets après un hard reset, donc j'aurais plutôt tendance à rester sur Ext3   )
 
Tourner sans journalisation, c'est vraiment pour des disques sans aucun mécanisme de wear-levelling, comme les cartes CF.
Un SSD récent est fait pour être utilisé quasiment comme un HDD classique.

Voila déjà une première réponse intéressante concernant le type de système de fichier
 
J'attends d'autres avis, allez, allez

j'ai utilisé du ext3 sur un ssd intel x25-m 80Go. Un reboot violent (electrique) a foutu le fs en rade. Alors qui incriminer? la faute à pas de chance? une faiblesse de ext3 (j'en doute)? le ssd?
 
enfin, ça m'inquiète un peu vu que ça va être pour un serveur, mais bon, on verra dans le temps.

@dek : j'aime bien la solution du RAMDisk pour le dossier ~/.mozilla, mais chez moi ça déconne un peu. Le fonctionnement est nickel, mais lors du shutdown, ça couille. A priori, le système tente de démonter le FS (/home) avant que rsync ait terminé. Du coup, FF pense qu'il s'est crashé en m'ouvre toujours la même session après un reboot. As-tu une idée ?
EDIT : laisse tomber, j'ai vidé mon profil .mozilla_ref, et tout fonctionne nickel, je sais pas ce qu'il y avait de pourri dedans, mais en tout cas ça empêchait le truc de fonctionner. Par contre j'ai toujours un message bizarre à l'arrêt de la machine : /dev/sda6 (mon /home) est occupé lors du démontage, que j'ai ou pas ajouté la ligne de ton astuce dans rc.local.shutdown. J'ai remarqué que cela ne se produit que si j'ai ouvert ma session graphique, un reboot un tty sans avoir ouvert une session graphique (juste KDM de lancé) ne pose pas de problème pour démonter /home.

Tu avais peut-être un peu trop de fichiers en cache offline ?
Aucune idée par contre pour ton problème de démontage

D'ailleurs, en dehors de cette astuce pour le profil, que faut-il changer dans la conf de FF pour qu'il utilise le moins possible le disque dur ? Il me semble que tu parlais de cache offline/online, mais je ne retrouve plus l'info

Tu vas sur la page "about:config" et tu filtres avec le mot-clé "browser.cache", là tu as tous les settings en rapport avec le cache, online et offline.

Mais à savoir que si tu utilises l'astuce du .mozilla en ram, ainsi que le /tmp en tmpfs, FF ne se servira jamais du disque, même le cache offline sera stocké en ram (d'où mon conseil de vérifier la taille qui lui est allouée pour ne pas remplir la ram).
Ben oui, avec FF, tout est stocké soit dans /tmp (pas grand chose, par exemple les streams flash) soit dans .mozilla/ .

Les écritures sur le disque ne se feront qu'au shutdown, avec un rsync.
(tu peux également placer le rsync dans un cron si tu veux synchroniser régulièrement)

Pour récapituler :
cache online -> RAM
cache offline -> HDD (.mozilla)
base de données sqlite -> HDD (.mozilla)
bordel genre cookies et compagnie -> HDD (.mozilla)
certains fichiers temporaires -> HDD (/tmp)

En définissant des tmpfs pour /tmp et .mozilla on place tout en ram au final.

OK, merci, c'est parfait

CF de 4Go ici et en ext3
Quelques tmpfs de rigueur (debian)

Création automatique du dossier /var/cache/apt/archives/partial via un script init.d (runlevel 2,3,4,5)

C'est rigolo, j'y pensais à midi, je me disais qu'avoir un tmpfs pour le cache du gestionnaire de paquets était peut être une bonne idée après l'installation de la distrib (où traditionnellement, on télécharge beaucoup). Du coup, je vais peut être le faire pour mon install sous Arch.

Ca dépend de la ram disponible. Pour moi ca va, j'ai un petit 1.5Go de libre, mais pour les petites config, ca peut faire mal un dl après installation.

 
Je le fais sur mon netbook sous Arch, j'ai simplement spécifié l'emplacement du cache dans la config de yaourt vers /tmp/yaourt_cache, mon /tmp étant en tmpfs    
 
Yaourt m'insulte seulement parce qu'il ne trouve plus l'ancien cache et doit donc le recréer, mais rien de plus.
Effectivement, ça pose le problème lors de grosses updates, ne pas oublier de nettoyer le cache après.

Dek, si tu as une seconde, peux-tu contrôler les informations que j'ai mise dans les premiers posts, notamment dans la partie III. Conseils et astuces. Les deux viennent de toi, au moins en partie, j'aimerais avoir ton aval que tout est correct. Merci d'avance

Pour la première partie, je trouve ça très très bien    
 
Juste une petite faute à wear-levelling    
(il y en a peut-être d'autres, j'ai juste noté celle-ci en lisant rapidement)
Et pour les perfs des SSD haut de gamme, il y a encore plus fort    
 
Pour le reste c'est parfait, et je te colle mon script d'init pour Debian (qui réalise la même chose que les /etc/rc.local.x mais pallie l'absence de rc.local.shutdown sous Debian) :
 

 
Pas raffiné, mais il fonctionne    
 
Sinon un petit lien "Sujets à lire" vers ce topic peut être de bon aloi, on y traite également de ces questions :
http://forum.hardware.fr/hfr/OSAlt [...] 9104_1.htm
 
Et je viens de me rappeller de cette discussion : http://forum.hardware.fr/hfr/OSAlt [...] 7924_1.htm

Le ramdisk est un peu dépassé il me semble, et tmpfs est plus souple (et permet aussi de modifier la taille allouée en ram plus simplement).
Le vidage de la partition en tmpfs se fait au démontage de celle-ci, et non au boot. On pourrait croire que la ram du pc agit comme un SSD quand il est éteins, mais non. La ram (hors mode veille spécifique) ne garde pas les données qu'elle contient en cas de coupure de courant.
 
Pour le blabla sur les SSD, il y a un topic en cat hardware ( [Topic Unique] FFD (Fast Flash Disk)/ SSD, pas si loin de nous).

Putain les prix des SSD chez G-Monster-Promise... Bon, on est clairement chez le professionnel par contre, d'autant plus que ça doit être plus ou moins à base de RAID ou quelque chose du genre pour atteindre ces débits. Ca sort un peu du cadre de ce topic je trouve, mais bon, je vais quand même en faire mention
 
Pour le reste, merci d'avoir pris le temps de relire et de linker quelques sujets et tout ça, ça aide à faire avancer le topic

Avant que je n'oublie, j'utilise sidux (debian sid avec un kernel spécifique adapté aux SSD). Si vous avez quelques pistes pour vérifier des réglages spécialements dédiés aux SSD, je suis preneur (sur le papier ca fait beau, mais je ne sais pas si c'est vraiment en place et fonctionnel).

 
Le terme RamDisk est un abus de langage ici, si tu regardes bien la méthode fait appel à tmpfs
 

 
À mon avis ça va arriver assez vite (le principe, pas ce SSD-là) chez les particuliers, placer le SSD sur PCI-E directement ça ne coûte pas vraiment beaucoup plus cher (contrôleur différent, simplement), et le potentiel en perfs est énormes.
Le seul écueil aux dernières nouvelles, c'est de pouvoir booter dessus.
Mais ça va être dispo plus vite chez les linuxiens que les windowsiens ça je pense  

Autant clarifier les choses dés le début oui.

Ce que j'aimerais savoir le plus vote possible, c'est comment partitionner et formater son SSD avec les partition alignée, bonne taille de bloc, etc...
 
Si quelqu'un a une méthode infaillible avec des outils libres, je suis preneur...

Déjà, ne pas faire de swap
 
A moins de vouloir cramer le SSD si la machine swap déjà bien d'habitude.
 
Mais c'est marrant de voir toute la ram occupée et de perdre le contrôle de la machine

 
Boarf c'est un peu pareil, avec le wear-levelling, si le swap n'est utilisé qu'occasionnellement, pas de problème, les écritures ne seront jamais faites sur les mêmes secteurs.
Et sans swap, pas d'hibernation.
Évidemment, si le swap est utilisé constamment, là ça peut devenir moins cool.

 
(j'ai vu l'appel dans le topic OCZ... tu devrais y mettre le lien d'ailleurs ! )

Certes, je le fait de suite

Sinon, j'ai ajouté un petit texte sur le choix du FS pour utiliser un SSD. Si vous avez des critiques à y faire, merci de poster et de proposer les modifications à apporter, histoire d'être le plus précis possible.

Edit :
D'ailleurs, un peu tout le monde, merci de me préciser la référence exact de votre SSD pour le recensement, ce sera d'autant plus précis.

Pour moi CF Transcend 300x 4Go branchée sur adaptateur CF-SATA (cherchez sur la bay le modèle rouge qui est décris comme plus rapide que le modèle bleu), j'hésite à me prendre une chinoise de 16Go en 300x, les 4Go sont un peu juste en utilisation desktop.

Avant de mettre ceci dans les premiers posts, j'aimerais avoir votre avis (cela concerna l'alignement des partitions) :
http://www.ocztechnologyforum.com/ [...] tcount=134
C'est assez convaincant, et ça reste très simple en plus je trouve, non ? C'est uniquement basé sur fdisk, ce qui reste quand même très tranquille.

Salut,
 
j'utilise pour ma part un SSD également (Samsung SLC 32 Go, j'ai oublié la réf exacte), j'ai aligné les partitions, et je ressens une amélioration des perfs.
Je vous fais part de mes réflexions.
 
Edit: Je précise qu'utiliser une feinte comme forcer fdisk à utiliser une taille de piste de 56 secteurs (fdisk -s 56 ...) n'est (à mon avis) pas du tout satisfaisant car:
- L'alignement est réalisé sur une taille de 4 Ko, alors qu'un SSD utilise (à priori) une taille de bloc de 64 Ko voire 128 Ko (à confirmer par les pros du hardware).
- Cette méthode ne tient pas compte du "décalage initial" imposé par MBR/Table des partitions en début de disque (voir plus loin).
/Fin Edit
 
Le plus gros problème pour aligner c'est que la gestion des partitions avec fdisk va se baser sur une "géométrie" de disque dur qui est virtuelle (cylindres, têtes, secteurs). Cette géométrie ne correspond à rien de réel et peut varier.
1) La seule donnée qui est toujours constante, c'est la taille d'un secteur: 512 octets. Il faut exploiter cette information et partitionner en comptant les secteurs.
2) Avec une table des partitions standard (msdos), le premier secteur (numéro 0) contient obligatoirement le MBR et la table des partitions. Si on ne le spécifie pas, la première partition commence au secteur numéro 1. Il faut tenir compte de ce décalage.
3) Il faut connaitre à l'avance la taille de bloc sur laquelle on souhaite s'aligner. Sur un SSD, la plupart des forums indiquent que cette taille est 128 Ko. Je n'ai aucune information sûre à ce sujet.
 
 
A partir de ces 3 éléments, on en déduit que:
1) La taille d'un bloc SSD, mesurée en secteurs, est de 256 (128 Ko / 512 o)
2) Pour aligner les partitions, il faudra que chaque début de partition commence à un secteur multiple de 256.
3) A cause de la table des partitions/MBR, la première partition devra commencer au secteur 256 (le secteur 0 est réservé, les secteurs 1 à 255 seront intentionnellement laissés inoccupés. Espace gaspillé: 255 secteurs = 127.5 Ko)
 
Supposons que je veuille partitionner comme suit (fictif):
/dev/sda1                 500 Mo
/dev/sda2                 2000 Mo
/dev/sda3                 10000 Mo
/dev/sda4                 3000 Mo
 
On calcule les tailles des partitions, en secteurs de 512 octets:
/dev/sda1      500 Mo = 500 * 1024 * 1024 / 512 = 1024000 secteurs
/dev/sda2      2000 Mo = 2000 * 1024 * 1024 / 512 = 4096000 secteurs
/dev/sda3      10000 Mo = 10000 * 1024 * 1024 / 512 = 20480000 secteurs
/dev/sda4      3000 Mo = 3000 * 1024 * 1024 / 512 = 6144000 secteurs
 
On calcule le positionnement des partitions sur le SSD. Il faut trouver le secteur de début et le secteur de fin:
/dev/sda1    début: 256       Fin: 256 + 1024000 - 1 = 1024255
/dev/sda2    début: 1024255 + 1 = 1024256         Fin: 1024256 + 4096000 - 1 = 5120255
/dev/sda3    début: 5120255+ 1 = 5120256      Fin: 5120256 + 20480000 - 1 = 25600255
/dev/sda4    début: 25600255+ 1 = 25600256     Fin: 24678456 + 6144000 - 1 = 31744255
 
Maintenant je connais la position des partitions.
On attaque le partitionnement avec Parted (en supposant que le SSD est au préalable vierge), qui permet de spécifier secteur de début/fin pour chaque partition:

 
Me voila avec des partitions alignées à 128 Ko.
Si vous utilisez fdisk pour visualiser les partitions, il va se plaindre que les fins de partitions ne correspondent pas à une limite de cylindre. Il faut ignorer cet avertissement (et ne plus utiliser fdisk).
 
 
Maintenant, il faut formatter les partitions.
Il existe (au moins dans EXT2/3/4 et dans XFS) la possibilité de spécifier un "stride size", paramètre normalement utilisé dans le cas de grappe RAID, où la notion d'alignement est aussi importante.
On peut ainsi optimiser le filesystem pour un alignement donné.
 
Issu de la page de man mkfs.ext4:

 
En EXT2/3/4, la taille d'un Stride est exprimée en nombre de blocs du filesystem (rien à voir avec la taille de blocs du SSD).
Normalement un bloc EXT2/3/4 a toujours une taille de 4 Ko (sauf sur les partitions de très petite taille). On peut forcer cette taille avec le paramètre -b 4096 .
 
Pour réaliser un formattage aligné au SSD, il faut compter la taille d'un bloc SSD (128 Ko) en nombre de blocs EXT (4 Ko).
Résultat: 128 / 4 = 32
 
On va donc formatter comme suit:
# mkfs.ext4 -b 4096 -E stride=32 /dev/sda1
 
 
Avec XFS, les paramètres sont différents mais le principe est inchangé.
 
Extrait du man mkfs.xfs:

 
Avec un bloc XFS = 4 Ko
Le "sunit" est la taille du bloc SSD exprimée en secteurs de 512 octets.
Donc: 128 Ko = 256 secteurs de 512 octets
 
La commande est donc:  (option -d pour la partie DATA et -l pour la partie LOG du filesystem)
# mkfs.xfs -b 4096 -d sunit=256 -l sunit=256 /dev/sda1
 
 
 
Par ailleurs, je me suis aperçu en installant Mandriva 2009.1 Spring, que DiskDrake, en passant en mode "Expert", permet de spécifier le "secteur de début" des partitions, et la taille des partitions en méga-octets.
En créant la première partition au secteur 256, puis en créant les autres de n'importe quelle taille (exprimée en Méga-Octets indivisibles), je vais obtenir naturellement un alignement à 128 Ko pour les partitions.
Reste le problème du formattage aligné, qui n'est pas pris en compte par DiskDrake (à ma connaissance).

Bordel... C'est vraiment pas simple leur affaire... Je pense qu'il va falloir que je relise une fois ou deux ton post pour essayer de tout comprendre. Le truc, c'est que j'aimerais bien ne pas avoir à m'y prendre en 18 fois pour installer mon SSD (qui devrait arriver dans les prochains jour), donc j'aimerais réaliser un partitionnement aligné du premier coup. Je vais essayer de reprendre ton post et de l'adapter à mon futur Vertex 120Go. J'avoue que je patauge un peu avec ces conneries...
En tout cas, merci pour ce post très instructif J'espère pouvoir en faire un genre de règle absolu à mettre dans les premiers posts pour que tout le monde puisse en profiter.

super ce topic  
moi j'ai 2x CF sandisk (une en 12Go ultra3 pour le / et une en 8Go ultra2 pour le /home)
ça fonctionne du tonnerre  (2go de ram pour être à l'aise / noswap, tmpfs, noatime et syslog down)

[albator], excuse moi, mais il y a quelque chose que je ne comprend pas très bien... Je reprends dans ton post :

Puis un peu plus loin, le tableau des partitions avec les secteurs :

Or les chiffres en gras, divisés par 256 donnent des résultats non entiers, à savoir respectivement 16400.21875 et 96400.21875. J'ai loupé un épisode ? J'ai juste rien compris ? Ou il y a une erreur dans ton raisonnement ?

EDIT : laisse tomber, j'ai trouvé le problème : tu as fait une faute de frappe dans l'addition de calcul de la fin de sda2 que tu as reprise sur toute la suite Tu as noté 102456 au lieu de 1024256. Et forcément ça change tout...

Re-Edit :
l'utilisation d'une partition étendue et de lecteurs logiques a-t-elle une influence quelquonque sur le calcul des secteurs ?

Re-re-Edit :
Apparemment, oui, ça change des choses. Je n'ai pas pu créer des lecteurs logiques avec les tailles exactes sur un disque de test alors que les même partitions en primaires passent sans soucis.

En me basant sur la méthode de [albator], je me suis fait un petit tableau sous OOo.Calc qui permet de calculer simplement, à partir de la taille souhaitée des partitions, les secteurs de début et de fin. Si il s'avère que cette méthode est une bonne méthode pour créer des partitions alignées sous Linux (pour l'instant elle me semble très bonne, mais j'aimerais être certain avant de mettre tout ça dans le premier post, etc, et notamment avoir l'avais d'autres personnes qui se sont penchées sur l'alignement), je diffuserai le tableau dans les premiers posts

Ouaip, j'ai fait tous les calculs de visu (pas en copiant/collant ma conf réelle), donc erreur potentielle. J'ai corrigé à nouveau de tête, normalement c'est bon.
En tout cas tu as raison, il est facile de vérifier la position de début de chaque partition en faisant simplement la division par 256.
 
Pour la partition étendue, à priori, son point de départ et de fin n'ont pas d'importance.
Ce sont les lecteurs logiques à l'intérieur de la partition étendue qui doivent être alignés, si c'est possible (pas testé). On doit pouvoir placer un "vide" de secteurs au début de la partition étendue pour que le 1er lecteur logique soit aligné, comme on l'a fait en début de disque.

drapal

J'ai un SSD Samsung P18000 quelque chose (le modèle Samsung des AOne) 8Go, formaté en ext4.
 
Il y a un naigateur plus léger qui écrit moins sur le disque (enfin je trouve), c'est Opera.
 
Mais le /tmp en tmpfs augmente en effet la rapidité générale

Très intéressant ça. Je pense justement un de ces moments à remplacer le HDD de mon portable. Donc merci.
- Petite question, le TRIM est supporté à partir de quelle version du noyau ?
- relis le paragraphe III désactiver le logging, il manque "plupart" au début.
Bonne soirée à tous