Les FS modernes (ZFS, Btrfs, ...) fournissent par défaut le copy on write et donc presque gratuitement, le premier point, la répartition des écritures sur l'ensemble du device.
Tout à fait. Vu qu'on s'en fout de la localité des accès sur un SSD, ce genre de fonctionnement n'est de plus pas pénalisant pour les SSD, contrairement aux disques classiques.
Ce qui supprime toutes la logique de garbage collection et de CoW au niveau du device.
Alors là pas du tout.
Mettons-nous dans le cas d'un SSD « complètement utilisé » (pas neuf) sans trim, i.e. sur lequel on a écrit au moins autant que sa capacité, et qui a donc tous ses secteurs marqués comme « occupés », quoiqu'en dise le FS dessus (même avec 100% d'espace libre) ; cas on ne peut plus classique pour un support de stockage utilisé normalement. Sa table (interne) de mapping des secteurs est faite d'une certaine manière, propre à sa manière de gérer la répartition des blocs et à l'utilisation qui en a été faite, et n'est pas forcément du tout contiguë par rapport aux secteurs tels qu'on les voit à plus haut niveau.
Quand une écriture pour le secteur S arrive, quel que soit la manière du FS d'écrire dessus, qu'il fasse du CoW ou autre, ton SSD va devoir trouver de la place pour l'écrire, à un endroit qui n'est pas le même que le précédent secteur qu'il remplace si c'est un FS style CoW, certes, mais de toute façon d'une manière où le SSD va devoir lui aussi changer son mapping car il y a beaucoup de chances qu'il doive déplacer tout un bloc (= plusieurs Mo) d'un endroit à un autre, en re-déplaçant d'autres secteurs au passage (= ré-écriture d'autres blocs également) afin de faire de la place (rappelons qu'il n'a plus de place libre, et qu'il doit donc trouver un endroit ou écrire = un bloc vierge dans son espace provisionné pour, dans lequel passera le secteur qui était précédemment présent à cet endroit selon le mapping du SSD). Tu n'as aucun contrôle sur le mapping interne du SSD, et même si tu voulais être optimiste et te dire qu'en faisant des écritures de la taille de « l'unité » qu'il utilise pour gérer son truc, ça serait « optimal », bah aujourd'hui les blocs c'est plusieurs Mo... (oui, il écrit par page, i.e. plusieurs centaines de Ko, mais je parle en erase-block pour simplifier)
Alors après, si ton contrôleur de SSD est pas trop con, il va pouvoir « agglutiner » plusieurs requêtes en écriture (tout en faisant gaffe à l'interaction avec la sémantique d'atomicité (ou pas) de la suite d'instructions qu'il reçoit) afin d'écrire des blocs plus gros, qui nécessiteront de moins faire de déplacement de secteurs, mais ça n'empêche qu'au final, la logique de garbage collection est au contraire beaucoup plus intense et compliquée, et ton amplification en écriture (= rapport de la taille de la requête en écriture / écritures réellement réalisées sur le SSD) est énorme, ce qui entraîne une dégradation de la durée de vie de ton SSD.
Pour ce qui est du 2ème point, il est toujours nécessaire mais ce n'est plus un trim, une opération potentiellement lourde**, mais juste un reset quand c'est fait au niveau du fs.
Je ne comprends pas ce que tu veux dire... tu parles d'un « reset » qui serait ton fstrim, mais fait régulièrement / automatiquement ?
Sur les FS non moderne (extX, ...), la véritable question c'est plutôt : « quand faire le trim ? A la demande ou une fois de temps à autre ? ». Je suis d'avis de le faire une fois de temps à autre.
Pour moi ça ne change pas tant que ça des FS modernes ; il y a la même problématique de répartition en dessous (sur le SSD).
[^] # Re: SSD « propres » ?
Posté par benoar . En réponse au journal De l'obsolescence programmée chez Crucial. Évalué à 3.
Tout à fait. Vu qu'on s'en fout de la localité des accès sur un SSD, ce genre de fonctionnement n'est de plus pas pénalisant pour les SSD, contrairement aux disques classiques.
Alors là pas du tout.
Mettons-nous dans le cas d'un SSD « complètement utilisé » (pas neuf) sans trim, i.e. sur lequel on a écrit au moins autant que sa capacité, et qui a donc tous ses secteurs marqués comme « occupés », quoiqu'en dise le FS dessus (même avec 100% d'espace libre) ; cas on ne peut plus classique pour un support de stockage utilisé normalement. Sa table (interne) de mapping des secteurs est faite d'une certaine manière, propre à sa manière de gérer la répartition des blocs et à l'utilisation qui en a été faite, et n'est pas forcément du tout contiguë par rapport aux secteurs tels qu'on les voit à plus haut niveau.
Quand une écriture pour le secteur S arrive, quel que soit la manière du FS d'écrire dessus, qu'il fasse du CoW ou autre, ton SSD va devoir trouver de la place pour l'écrire, à un endroit qui n'est pas le même que le précédent secteur qu'il remplace si c'est un FS style CoW, certes, mais de toute façon d'une manière où le SSD va devoir lui aussi changer son mapping car il y a beaucoup de chances qu'il doive déplacer tout un bloc (= plusieurs Mo) d'un endroit à un autre, en re-déplaçant d'autres secteurs au passage (= ré-écriture d'autres blocs également) afin de faire de la place (rappelons qu'il n'a plus de place libre, et qu'il doit donc trouver un endroit ou écrire = un bloc vierge dans son espace provisionné pour, dans lequel passera le secteur qui était précédemment présent à cet endroit selon le mapping du SSD). Tu n'as aucun contrôle sur le mapping interne du SSD, et même si tu voulais être optimiste et te dire qu'en faisant des écritures de la taille de « l'unité » qu'il utilise pour gérer son truc, ça serait « optimal », bah aujourd'hui les blocs c'est plusieurs Mo... (oui, il écrit par page, i.e. plusieurs centaines de Ko, mais je parle en erase-block pour simplifier)
Alors après, si ton contrôleur de SSD est pas trop con, il va pouvoir « agglutiner » plusieurs requêtes en écriture (tout en faisant gaffe à l'interaction avec la sémantique d'atomicité (ou pas) de la suite d'instructions qu'il reçoit) afin d'écrire des blocs plus gros, qui nécessiteront de moins faire de déplacement de secteurs, mais ça n'empêche qu'au final, la logique de garbage collection est au contraire beaucoup plus intense et compliquée, et ton amplification en écriture (= rapport de la taille de la requête en écriture / écritures réellement réalisées sur le SSD) est énorme, ce qui entraîne une dégradation de la durée de vie de ton SSD.
Je ne comprends pas ce que tu veux dire... tu parles d'un « reset » qui serait ton fstrim, mais fait régulièrement / automatiquement ?
Pour moi ça ne change pas tant que ça des FS modernes ; il y a la même problématique de répartition en dessous (sur le SSD).