Re: Installation sur un SSD
On 2016-01-21 23:05:52 +0100, Pascal Hambourg wrote:
> Vincent Lefevre a écrit :
> > On 2016-01-21 00:56:47 +0100, Pascal Hambourg wrote:
> >> Francois Lafont a écrit :
> >>> On 20/01/2016 09:49, Pascal Hambourg wrote:
> >>>
> >>>> Si j'ai bien compris, le ramasse-miettes traite les pages et blocs
> >>>> contenant deux types de données :
> >>>> - les données rendues obsolètes par TRIM ;
> >>>> - les données rendues obsolètes par une écriture plus récente.
> >>>>
> >>>> Même sans TRIM, le ramasse-miettes peut traiter le deuxième type de
> >>>> données. Et je ne vois pas de raison d'attendre que l'overprovisionning
> >>>> soit épuisé pour commencer à agir. Il peut se déclencher en tâche de
> >>>> fond dès que le taux de réécriture atteint un seuil donné.
> >>>
> >>> Perso, j'ai aussi du mal à comprendre comment le SSD s'en sort sans TRIM.
> >>> Le cas 2 (écriture plus récente), c'est si je réécris sur un fichier de
> >>> mon file system déjà existant et non supprimé, non ?
> >>
> >> Pas seulement. C'est si tu réécris un secteur dans lequel tu as déjà
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> écrit. Peu importe que ce soit une mise à jour de méta-données, une
^^^^^
> >> modification d'un fichier existant ou la réutilisation d'un bloc qui
> >> contenait auparavant un fichier supprimé. Le SSD fonctionne au niveau du
> >> secteur et ignore la notion de fichier, existant ou supprimé.
> >
> > Cela suppose que le système va réutiliser de préférence un bloc d'un
> > fichier supprimé.
>
> Pourquoi "de préférence" et "d'un fichier supprimé" ?
Cf ce que j'ai souligné ci-dessus. Si le système ne fait pas une telle
réécriture mais va plutôt écrire dans des secteurs qui n'ont jamais
été utilisés, le SSD ne pourra pas savoir que les données du fichier
supprimé sont maintenant libres.
> Comme je l'ai déjà mentionné le ramasse-miettes concerne n'importe quel
> bloc réécrit pour n'importe quelle raison. Les préférences d'allocation
> du système de fichiers n'entrent pas en ligne de compte.
Si. Cf ci-dessus.
> > Cela présuppose aussi que le bloc entier doit être
> > réutilisé explicitement par le système.
>
> Non. Voir plus bas.
>
> > Je vais donner un exemple.
> > Admettons qu'après suppression de fichiers, un bloc du SSD (64 pages)
> > ait été libéré. Ensuite, le système cherche à réutiliser des pages de
> > ce bloc pour écrire un petit fichier, disons 4 pages (16 Ko au total).
>
> Note : le système hôte ignore tout de l'organisation des pages et blocs
> du SSD (à part éventuellement leur taille) tout comme le SSD ignore tout
> de l'organisation des fichiers du système hôte.
>
> Dire que le système hôte cherche à réutiliser des pages d'un bloc n'a
> pas de sens.
Si. Il suffit de réutiliser des secteurs de ces fichiers supprimés.
J'aurais peut-être dû dire: Ensuite, le système cherche à réutiliser
des secteurs de ces fichiers supprimés; et ces secteurs se trouvent
dans le bloc du SSD considéré (c'est le "Admettons").
> Tout ce que fait le système hôte, c'est réutiliser des
> secteurs logiques.
>
> > Le problème est que sans TRIM, le SSD ne sait pas que les 60 autres
> > pages du bloc ont été libérées. Il va donc:
> >
> > 1) soit devoir faire une copie du bloc (ce qu'on voulait éviter),
>
> Il ne fera cela que s'il ne reste aucune page libre dans aucun bloc.
>
> > 2) soit stocker les 4 pages dans des zones effacées et marquer les
> > 4 pages du bloc considéré plus haut comme libres.
>
> Voilà.
>
> > Le (2) ne va fonctionner que si au bout d'un moment, on espère que
> > toutes les pages du bloc vont être marquées comme inutilisées, ce
> > qui n'est possible que si le système va réutiliser toutes les pages
> > du bloc pour de nouveaux fichiers.
>
> Pas forcément. Le ramasse-miettes ne fait pas qu'effacer les blocs ne
> contenant que des données invalides. Comme je l'ai déjà écrit, il peut
> aussi recopier les données valides d'un bloc dans des pages libres
> d'autres blocs pour pouvoir l'effacer. Il ne faut juste pas le faire
> trop aggressivement car cela augmente le phénomène d'amplification
> d'écriture. D'un autre côté si on ne le fait pas assez, ce que tu
> évoques (lecture-effacement-écriture) risque de se produire, ce qui
> augmente également de l'amplification d'écriture.
C'est ce que je dis plus bas. La question est de savoir si tous les
SSD le font. D'autre part, si le SSD est utilisé en permanence (e.g.
serveur de fichiers), ça risque de le ralentir (alors que TRIM
permettrait d'éviter certains regroupements inutiles).
> > De plus, avec (2), il n'y a plus de correspondance entre contiguïté
> > logique et contiguïté physique,
>
> Comme je l'ai déjà écrit, cette correspondance n'a jamais existé.
Tout dépend des algorithmes utilisés.
> > d'où un phénomène de fragmentation
> > que le système ne peut pas gérer s'il le voulait
>
> Il n'en a pas besoin, la fragmentation des données d'un SSD n'a pas
> d'influence sur le temps d'accès.
La fragmentation va cependant nécessiter le regroupement de pages pour
libérer des blocs, ce qui, je pense, peut avoir une influence sur le
temps d'accès lorsque le disque est utilisé en permanence.
> > (mais si le SSD est capable de regrouper des pages utilisées en
> > arrière-plan pour faire apparaître des blocs entièrement libres,
> > c'est OK).
>
> Voilà.
--
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: