Installation sur un SSD

Vincent Lefevre a écrit :
> On 2016-01-18 09:43:35 +0100, Pascal Hambourg wrote:
>> Je n'ai pas regardé cette page, mais certains SSD haut de gamme ont un
>> taux d'overprovisionning élevé, pouvant aller jusqu'à 100%. Dans ce cas
>> il reste toujours une grande quantité de blocs libres même sans TRIM, ce
>> qui permet au ramasse-miettes de fonctionner efficacement. On peut
>> obtenir un résultat similaire en n'utilisant qu'une fraction de la
>> capacité utile d'un SSD standard.
>
> J'ai des doutes là-dessus. Lorsqu'il y a une modification d'un
> fichier:
>
> 1) Si le système cherche à réécrire sur les pages utilisées, ça va
> provoquer des effacements / copies, ce qui est lent.
>
> 2) S'il cherche au contraire à utiliser des zones libres (tant qu'il
> y en a), il va prendre de plus en plus de données, tel que c'est
> vu par le SSD. Et au bout d'un moment, tout sera occupé, et on
> retombe dans le cas 1 (s'il ne fait pas lui-même de TRIM).

C'est pour éviter d'en arriver là que le SSD fait du ramasse-miettes :
compactage et copie des pages à jour dans de nouveaux blocs, et
effacement des blocs libérés.

On 2016-01-18 21:26:16 +0100, Pascal Hambourg wrote:

Vincent Lefevre a écrit :

On 2016-01-18 09:43:35 +0100, Pascal Hambourg wrote:

Je n'ai pas regardé cette page, mais certains SSD haut de gamme ont un
taux d'overprovisionning élevé, pouvant aller jusqu'à 100%. Dans ce cas
il reste toujours une grande quantité de blocs libres même sans TRIM, ce
qui permet au ramasse-miettes de fonctionner efficacement. On peut
obtenir un résultat similaire en n'utilisant qu'une fraction de la
capacité utile d'un SSD standard.

J'ai des doutes là-dessus. Lorsqu'il y a une modification d'un
fichier:

1) Si le système cherche à réécrire sur les pages utilisées, ça va
provoquer des effacements / copies, ce qui est lent.

2) S'il cherche au contraire à utiliser des zones libres (tant qu'il
y en a), il va prendre de plus en plus de données, tel que c'est
vu par le SSD. Et au bout d'un moment, tout sera occupé, et on
retombe dans le cas 1 (s'il ne fait pas lui-même de TRIM).

C'est pour éviter d'en arriver là que le SSD fait du ramasse-miettes :
compactage et copie des pages à jour dans de nouveaux blocs, et
effacement des blocs libérés.

Oui, mais le ramasse-miettes du SSD ne fonctionne bien que si TRIM est
utilisé. L'overprovisionning va juste retarder le moment où l'absence
de TRIM posera des problèmes de performance.

Qu'est-ce qui te permet d'affirmer cela ? Le ramasse-miettes fonctionne
mieux avec TRIM, mais il fonctionne quand même bien sans TRIM.

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é.

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 ?

Je prends un cas bête et stupide : j'ai mon SSD, je n'utilise jamais fstrim
et je passe mon temps à écrire (avec dd par exemple) un fichier de 20GB
puis à le rm et ainsi de suite. Un truc genre :

c=0
while true
do
dd if=/dev/zero of=/home/flaf/f$c bs=1G count
rm /home/flaf/f$c
c=$((c+1))
sleep 60
done

Là, il fait comment le ramasse-miette du SSD ?

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é.

Je prends un cas bête et stupide : j'ai mon SSD, je n'utilise jamais fstrim
et je passe mon temps à écrire (avec dd par exemple) un fichier de 20GB
puis à le rm et ainsi de suite. Un truc genre :

c=0
while true
do
dd if=/dev/zero of=/home/flaf/f$c bs=1G count
rm /home/flaf/f$c
c=$((c+1))
sleep 60
done

Là, il fait comment le ramasse-miette du SSD ?

Il est susceptible d'intervenir dès que le système écrit un nouveau
fichier à l'emplacement d'un ancien. En interne, l'écriture des
nouvelles données se fera dans des pages différentes pour éviter la
lecture-effacement-écriture, et les pages contenant les anciennes
données seront candidates au ramasse-miettes.