View previous topic :: View next topic |
Author |
Message |
El_Goretto Moderator
Joined: 29 May 2004 Posts: 3169 Location: Paris
|
Posted: Thu Sep 15, 2011 10:35 am Post subject: [SSD/LVM] Alignement, encore et toujours |
|
|
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"
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"
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
Suite sous peu. _________________ -TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
Back to top |
|
|
El_Goretto Moderator
Joined: 29 May 2004 Posts: 3169 Location: Paris
|
Posted: Thu Sep 15, 2011 1:39 pm Post subject: |
|
|
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. _________________ -TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
Back to top |
|
|
bdouxx Tux's lil' helper
Joined: 28 Dec 2009 Posts: 117
|
Posted: Mon Sep 19, 2011 7:49 pm Post subject: |
|
|
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? |
|
Back to top |
|
|
El_Goretto Moderator
Joined: 29 May 2004 Posts: 3169 Location: Paris
|
Posted: Mon Sep 19, 2011 10:55 pm Post subject: |
|
|
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). |
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? |
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)
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...
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 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 _________________ -TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
Back to top |
|
|
GentooUser@Clubic l33t
Joined: 01 Nov 2004 Posts: 829
|
Posted: Tue Sep 20, 2011 11:17 pm Post subject: |
|
|
À 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. |
|
Back to top |
|
|
El_Goretto Moderator
Joined: 29 May 2004 Posts: 3169 Location: Paris
|
Posted: Wed Sep 21, 2011 11:22 am Post subject: |
|
|
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 _________________ -TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|