Re: Installation sur un SSD
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é" ?
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.
> 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. 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.
> 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é.
> 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.
> (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à.
Reply to: