# [SSD/LVM] Alignement, encore et toujours

## El_Goretto

Une promo aura eu raison des dernières miettes de ma volonté, après mes tests sur un petit modèle, j'ai craqué pour un SSD en version "homme", un M4 de 256Go.

Alors on est reparti dans le partitionnement & co.

Ce coup-ci, je me fends d'une partition racine aussi en LVM (d'ailleurs connaissez-vous dracut (dans portage)? Juste ça roxx des poneys pour les gens qui aiment les kernels customs mais n'ont pas une passion immodérée des initrd. En plus, ça mange du plymouth au petit déjeuner, je teste çà...).

Et là, l'éternelle question: du ext4 dans un lv dans un vg dans un pv... Hop, au boulot.

Ce thread va me servir de journal de bord et d'éponge à feedback/remarques, éventuellement en vue de rédiger une howto propre et simple par la suite.

Etape 1: choper les specs de son SSD, à savoir la taille de l'erase block: 512Ko pour la plupart des modernes (Sandforce et Marvell), éventuellement 128K sur certains plus anciens.

Etape 2: Partitionner et créer les PVs. On en déduit donc qu'aligner ses partitions physiques à partir du 2048ème secteur (de 512o, soit 1Mo) du début du disque, ça le fait pour tout et n'importe quoi (même win7 le fait, c'est dire), fdisk dans ses versions récentes propose de faire la même chose par défaut. Logiquement, que l'erase block soit 512Ko, 128Ko, c'est tout pareillement divisible.

Etape 3: Formater les PVs. Jusqu'à maintenant, les recettes que j'avais vu utilisait des gruges un peu dégeulasse (avec des arrondis et tout) à base de metadatasize (en fixe en plus, sur 256K, ça colle pas avec les erase block de 512K), mais j'ai trouvé quelqu'un qui conseillait plutôt de jouer sur l'option --dataalignment... qui, s'il fait ce qu'il semble vouloir dire, a le mérite de s'adapter clairement à nos besoins.

Sur ce point, vous êtes invités à commenter "pvcreate --dataalignment 512k /dev/sdXX"  :Smile: 

Etape 4: Création du VG. En lisant la manpage de pvcreate et de cet option en particuliers, on nous invite à ne pas oublier de jouer sur PhysicalExtentSize de vgcreate. C'est noté... Et "RFC" aussi ici sur "vgcreate --physicalextentsize 512k vg_ssd /dev/sdXX"  :Smile: 

Bien entendu, on créera un VG dédié au SSD. A moins d'en avoir plusieurs du même type, certes. En théorie, j'ai des doutes sur l'intérêt de cette étape, car la valeur par défaut (4Mo) est déjà correcte en ce qui nous concerne.

Etape 5: Création des LVs. Là, pas vu d'option en particuliers, logiquement l'alignement "LVM" va découler des étapes 3 et 4. Enfin je crois... Aïe, point à creuser. Des remarques?

Etape 6: Formater les LVs. Bon, là, suite un peu plus tard, le temps que je retrouve mon super bookmark avec le truc qui vous calcul ce qui va bien à passer à mkfs.ext4  :Smile: 

Suite sous peu.

----------

## El_Goretto

Bon, pour l'étape 6, je n'arrive plus à remettre la main dessus, et le lien vers le blog du dev ext4 est HS.

Bon, pour l'histoire du calcul des valeurs de stride and co pour ext4, j'ai remis la main sur cette page, où on explique simplement comment faire pour calculer (simplement!) les valeurs requises:

stride = taille erase block / taille block FS. Soit 512k/4k = 128 (4k pour ext4 est la valeur par défaut, au pire pour être sûr, on la force).

stripe-width = stride dans notre cas, on n'a qu'un seul SSD et pas de RAID logiciel.

Ce qui donne la ligne suivante: "mkfs.ext4 -b 4096 -E stride=128,stripe-width=128 /dev/vg_ssd/lv_XX"

Pareil, à vos commentaires.

----------

## bdouxx

bonjour

Dans ton autre topic:

 *Quote:*   

> Pour mettre un Linux sur un SSD, je pensais tout mettre sauf /usr/src (les kernels), et /usr/portage, voire /var et /tmp pour les extrémistes (ou bien seulement /var/tmp pour l'espace de compilation portage et ccache). 

 

Si j'ai bien compris c'est pour limiter l'usure, mais on gagne combien d'années de durée de vie?est ce vraiment significatif?

A l'inverse, le fait d'utiliser LVM, ne va t'il pas engendrer une usure plus rapide du ssd et une baisse des performances? Car tu partitionnes le ssd en petites partitions que tu augmenteras en fonction des tes besoins, si je ne me trompe pas. Et donc tu écriras plus ou moins toujours au mêmes endroits ... Mais je ne maitrise franchement pas le sujet, et préfère donc poser la question.

J'ai l'impression que les SSD évoluent assez rapidement pour me dire que si j'en achète un maintenant, Je le changerai d'ici 5 à 10 ans... Mais faut pas que ca pete avant.

Je me voyais donc plutôt en acheter un (style OCZ Vertex2 120Go mais en ne comptant en utiliser que la moitié)  mettre tout ce qui concerne gentoo sur ce disque et mettre le reste sur mes disques durs classiques actuels et tout ca sans utiliser LVM... Bref l'opposé de toi, mais sans vraiment avoir d'argument pour à par la simplicité( je serais plutôt du genre a suivre des docs d'install que d'innover dans ce domaine la.)... Qu'en penses tu?

----------

## El_Goretto

 *bdouxx wrote:*   

> bonjour
> 
> Dans ton autre topic:
> 
>  *Quote:*   Pour mettre un Linux sur un SSD, je pensais tout mettre sauf /usr/src (les kernels), et /usr/portage, voire /var et /tmp pour les extrémistes (ou bien seulement /var/tmp pour l'espace de compilation portage et ccache).  
> ...

 

Il y a pas mal d'articles qui ont fait le calcul de la durée de vie d'un SSD avec tant de quantité écrite par jour (généralement, en Go). Je te renvois vers google (anandtech est très bon sur les technos SSD, c'est ma bible)  :Smile: 

Après chacun s'investit comme il veut dans un setup plus ou moins compliqué, hein, par exemple, par rapport à mes plans initiaux, les sources kernels sont finalement sur le SSD, et /var sur un HDD, et /var/tmp/portage et /tmp en tmpfs. Franchement, pas convaincu que ça vaille la peine de s'embêter, mais c'est comme tout, j'avais envie de le faire...  :Smile: 

 *bdouxx wrote:*   

> A l'inverse, le fait d'utiliser LVM, ne va t'il pas engendrer une usure plus rapide du ssd et une baisse des performances? Car tu partitionnes le ssd en petites partitions que tu augmenteras en fonction des tes besoins, si je ne me trompe pas. Et donc tu écriras plus ou moins toujours au mêmes endroits ... Mais je ne maitrise franchement pas le sujet, et préfère donc poser la question.

 

Le "wear leveling" est géré en interne par le contrôleur du SSD. Il n'y aura pas plus ou moins d'écriture "au même endroit" avec ou sans LVM. Et ça fait des années que LVM s'est généralisé partout dans le milieu professionnel, sans jamais se plaindre d'une baisse de perfs... D'où le défi présent, aligner toute la chaîne.

 *bdouxx wrote:*   

> J'ai l'impression que les SSD évoluent assez rapidement pour me dire que si j'en achète un maintenant, Je le changerai d'ici 5 à 10 ans... Mais faut pas que ca pete avant.
> 
> Je me voyais donc plutôt en acheter un (style OCZ Vertex2 120Go mais en ne comptant en utiliser que la moitié)  mettre tout ce qui concerne gentoo sur ce disque et mettre le reste sur mes disques durs classiques actuels et tout ca sans utiliser LVM... Bref l'opposé de toi, mais sans vraiment avoir d'argument pour à par la simplicité( je serais plutôt du genre a suivre des docs d'install que d'innover dans ce domaine la.)... Qu'en penses tu?

 

Ce n'est pas vraiment l'opposé de moi... mes données ne sont pas sur le SSD.

La loi de l'emmerdement minimal s'applique toujours, et à mon avis est tout à fait valable dans ce cas aussi  :Smile:  Tout sur le SSD et basta, les quantités écrites sur les partitions systèmes tous les jours sont faibles. Par contre, je t'encourage à utiliser LVM, franchement, là c'est des embêtements futurs que tu t'éviterais  :Smile: 

----------

## GentooUser@Clubic

À mon avis /var (à l'exception de /var /tmp) peut rester sur ssd, il ne représente pas tant d'écritures que ça (quelques mo par jour au plus) et les caches qu'ils contient (eix, portage, locate) ne seront que plus rapides. Seul risque un flood dans /var/log, pour ça que je l'ai viré sur le hdd.

----------

## El_Goretto

 *GentooUser@Clubic wrote:*   

> À mon avis /var (à l'exception de /var /tmp) peut rester sur ssd, il ne représente pas tant d'écritures que ça (quelques mo par jour au plus) et les caches qu'ils contient (eix, portage, locate) ne seront que plus rapides. Seul risque un flood dans /var/log, pour ça que je l'ai viré sur le hdd.

 

Même sans flood particuliers dans /var/log, n'importe qu'elle ligne ajoutée pourrait provoquer pour 512k d'écriture, au pire... Ceci dit, ta proposition avec /var/tmp et /var/log sur hdd et /var sur SSD me semble pas mal (si on enlève ccache de l'équation... ou qu'on le déplace).

Ceci dit, on dévie un peu du sujet, hein, j'ai toujours pas eu vos remarques au cas où j'aurai dis des âneries dans mes premiers posts  :Smile: 

----------

