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.
