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

Re: Installation sur un SSD



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é. Cela présuppose aussi que le bloc entier doit être
réutilisé explicitement par le système. 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).
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),

  2) soit stocker les 4 pages dans des zones effacées et marquer les
     4 pages du bloc considéré plus haut comme libres.

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. Effectivement, l'overprovisionning
va aider car cela augmente la probabilité qu'un bloc devienne
entièrement libre (à la connaissance du SSD) avant de manquer de
zones effacées, mais de là à dire que TRIM "n'est pas nécessaire",
ce n'est pas gagné...

De plus, avec (2), il n'y a plus de correspondance entre contiguïté
logique et contiguïté physique, d'où un phénomène de fragmentation
que le système ne peut pas gérer s'il le voulait (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).

-- 
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: