[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Installation sur un SSD



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 <vincent@vinc17.net> - 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)


Reply to: