Re: Installation sur un SSD
Francois Lafont a écrit :
>
> Ok, donc si je comprends bien le SSD n'est pas capable de distinguer les pages
> qui contiennent des données devenues inutiles pour le file system de celles
> qui restent encore d'actualité (ie utiles pour le fs).
Exact.
> Ok, TRIM indique seulement au SSD les data qui sont devenues inutiles au fs.
Oui.
>> Au début, toutes les pages sont vides, tout va bien. On écrit donc sans
>> avoir besoin d'effacer. Quand les données d'une page doivent être
>> modifiées, on écrit les nouvelles données dans une autre page vide et on
>> marque l'ancienne page comme obsolète. C'est rapide. Au passage on devine
>> qu'il n'y a plus de correspondance entre l'adresse d'un secteur et sa
>> position physique. Si on ne fait rien, à force d'écrire et de modifier
>> les données, toutes les pages vont finir par être écrites, qu'elles
>> contiennent des données obsolètes ou actuelles. Pour continuer à écrire,
>> il va falloir effacer des blocs de pages contenant des données
>> obsolètes.
>
> Mais là, je ne pige pas. Si le SSD n'est pas capable de savoir ce qui
> est actuel de ce qui est obsolètes sans TRIM, je ne vois pas comment
> il fait pour dégager de la place pour les prochaines écritures ? Si jamais
> je n'utilise pas l'option de montage discard et si en plus je ne lance _jamais_
> la commande fstrim, comment fait le SSD pour déterminer tout seul les data
> qui sont obsolètes de celles qui ne le sont pas ?
Il y a deux niveaux d'obsolescence des données :
- les secteurs marquées avec TRIM ;
- les pages dont les données ont été modifiées et réécrites dans une
autre page, comme décrit ci-dessus. En effet contrairement à un disque
dur les données actualisées ne sont pas écrites en place car cela
nécessiterait la copie et l'effacement préalable du bloc entier.
Pour avoir une réserve de blocs libres même si le SSD semble plein, le
SSD garde des blocs qui ne sont pas comptés dans la capacité utilisable.
Par exemple, un SSD d'une capacité utile de 120 Go aurait en réalité une
capacité 128 brute de 128 Gio (137 Go). On appelle cela
"over-provisionning".
> Ok, mais je ne vois pas comment le garbage collector du SSD va faire
> du coup pour savoir ce qui obsolète de ce qui ne l'est pas puisque j'ai
> cru comprendre qu'il ne pouvait pas le savoir sans le lancement de fstrim ?
Cf. ci-dessus. Le ramasse-miettes concerne les deux niveaux
d'obsolescence. Même sans TRIM, il reste les données obsolètes parce que
réécrites.
>> Pour que cela soit efficace il vaut mieux que le
>> système d'exploitation utilise comme unité de stockage des blocs de
>> secteurs coïncident avec une ou plusieurs pages du SSD (d'où les
>> contraintes nouvelles d'alignement des partitions),
>
> Si je fais commencer mes partitions à 1MiB, suis-je à l'abri de problèmes d'alignement ?
J'ai lu que certains SSD auraient une taille de bloc d'effacement
supérieure, de 2 Mio. Mais ce qui compte c'est surtout l'alignement avec
les pages du SSD, dont la taille maximum semble être 8 Kio. Idéalement
il faudrait donc dans ce cas utiliser en plus une taille de bloc égale
ou multiple. Or la taille de bloc par défaut des systèmes de fichiers
est souvent 4 Kio.
>> Le TRIM en lui-même ne fait que marquer les données obsolètes, il
>> n'efface rien. Un firmware de SSD bien conçu ne devrait pas déclencher
>> le ramasse-miette en fonction de la fréquence du TRIM mais seulement en
>> fonction du nombre de blocs libres et du taux d'écriture.
>
> Ok, mais alors comme ça a été dit dans un message précédent, il est recommandé
> de faire un fstrim une fois par semaine, c'est ça ?
Je n'ai pas d'avis ni d'expérience sur la question. En toute rigueur,
cela dépend de l'utilisation, en combien de temps la vitesse d'écriture
commence à baisser sans TRIM.
> Je n'arrive plus à retrouver le lien probant mais il me semble bien avoir lu
> quelque part que faire un fstrim de temps en temps n'était pas nécessaire sur
> certains disques SSD, est-ce vrai ? Par exemple (certes ce n'est pas très probant
> comme lien), ici http://www.mail-archive.com/ceph-users%40lists.ceph.com/msg12756.html
> un admin écrit :
>
> « Of course if you're using Intel DC 3700S SSDs you probably won't get any
> speed benefit from this at least, they're never slowing down. ^^ »
Je n'ai pas regardé cette page, mais certains SSD haut de gamme ont un
taux d'overprovisionning élevé, pouvant aller jusqu'à 100%. Dans ce cas
il reste toujours une grande quantité de blocs libres même sans TRIM, ce
qui permet au ramasse-miettes de fonctionner efficacement. On peut
obtenir un résultat similaire en n'utilisant qu'une fraction de la
capacité utile d'un SSD standard.
> On est d'accord que fstrim est valable uniquement pour des partitions avec
> file system, n'est-ce pas ? Par exemple si une application utilise un partition
> brute sans file system (je pense à Ceph par exemple qui utilise des partitions
> brutes où il écrit de manière séquentielle dessus), alors le fstrim n'y est
> pas nécessaire ?
C'est une bonne question. A ma connaissance fstrim ne fonctionne qu'avec
un système de fichiers (d'où son préfixe "fs") monté. Par contre
TRIM/discard peut être utilisé aussi avec le swap, les partitions RAID,
volumes LVM ou les volumes chiffrés. L'information des blocs obsolètes
est transmise en cascade de la couche supérieure à la couche inférieure.
Une application qui écrit directement sur le disque pourrait avoir sa
propre version de fstrim pour notifier les données obsolètes.
Reply to: