On 2016-01-18 06:00:49 +0100, Francois Lafont wrote: > On 17/01/2016 20:41, Pascal Hambourg wrote: > > C'est impossible puisque le TRIM sert justement à l'informer des blocs > > qui ne sont plus occupés. Certains SSD ont essayé de faire ça > > d'eux-mêmes mais ne savaient lire que NTFS. Inutile de dire qu'avec les > > autres systèmes de fichiers, ça a été la catastrophe. > > 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). [...] > > Rien n'oblige le SSD a effacer immédiatement suite à une commande TRIM. > > Ok, TRIM indique seulement au SSD les data qui sont devenues inutiles au fs. [...] > 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 ?
J'essaie de résumer visuellement, si j'ai bien compris. Disons qu'on a des blocs qui contiennent chacun 8 pages, avec la signification suivante pour les pages: U: utilisée par le FS I: inutilisée par le FS mais seul le FS le sait Y: inutilisée par le SSD (mais contient des données) Z: pas de données On suppose qu'à un moment, il n'y a plus de bloc effacé disponible et on a pour un bloc donné: 12345678 IIUUIIII Si une écriture doit se faire en page 1, alors le SSD doit lire le bloc, l'effacer, et le réécrire, et on obtient: 12345678 UIUUIIII Si une écriture doit se faire en page 2, alors le SSD doit lire le bloc, l'effacer, et le réécrire, et on obtient: 12345678 UUUUIIII Bref, à chaque écriture de page, on a un cycle lecture/effacement/écriture sur tout le bloc. Maintenant, si on fait un fstrim, on se retrouve avec: 12345678 YYUUYYYY Si une écriture doit se faire en page 1, alors le SSD doit lire les pages utilisées, effacer le bloc, et réécrire les pages utilisées, et on obtient: 12345678 UZUUZZZZ Si une écriture doit se faire en page 2, alors le SSD peut juste écrire dedans: 12345678 UUUUZZZZ C'est donc beaucoup plus rapide. Si on doit réécrire dans une page utilisée (e.g. pour la modifier), alors ça devient lent, mais je suppose que le système (driver) évite ce genre de chose si possible. Voilà, il y a quelques jours, il me semblait que les gros accès disque étaient devenus beaucoup plus lents (au moins en écriture) avec ma machine de bureau, et je me demandais pourquoi. C'est peut-être la raison. J'ai installé ma machine début octobre 2015, et je n'étais pas au courant du TRIM pour les SSD. Cette enfilade tombe donc bien! J'ai aussi un portable avec SSD depuis juin, mais je n'ai pas trop fait attention. -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
