Re: Installation sur un SSD

[Vincent Lefevre]

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 fragmentatio

Re: Installation sur un SSD

[Pascal Hambourg]

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

Re: Installation sur un SSD

[Vincent Lefevre]

On 2016-01-21 13:28:39 +0100, jdd wrote:
> Le 21/01/2016 13:04, Vincent Lefevre a écrit :
> 
> > 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).
> > 
> la fragmentation, pour un ssd, ce n'est pas critique, vu qu'il n'y a pas de
> tête à déplacer :-)

Il n'y a pas de tête à déplacer, mais vu que les effacements se font
par bloc, ça pose aussi des problèmes (mais complètement différents).
Par exemple, si on supprime un fichier de 64 pages qui tient sur un
seul bloc, on libère tout un bloc. Mais si chaque page se trouve sur
un bloc différent, ça libère seulement un petit bout de bloc pour
chacun des 64 blocs. Et à chaque réutilisation d'un tel petit bout
de bloc, il y a un effacement/copie de bloc à faire.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Installation sur un SSD

[jdd]

Le 21/01/2016 13:04, Vincent Lefevre a écrit :


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

la fragmentation, pour un ssd, ce n'est pas critique, vu qu'il n'y a pas 
de tête à déplacer :-)


jdd

Re: Installation sur un SSD

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Installation sur un SSD

[Francois Lafont]

On 21/01/2016 00:56, 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é.
> 
>> 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=20
>> 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.

Ok, merci encore Pascal d'avoir pris le temps de nous donner toutes ces
explications vraiment intéressantes. Il va falloir que je me fasse une
petite note perso pour résumer tout ça et être sûr d'avoir bien tout
compris, mais je crois que c'est clair maintenant. ;)

Merci encore.
À+


-- 
François Lafont

Re: Installation sur un SSD

[Pascal Hambourg]

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=20
> 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.

Re: Installation sur un SSD

[Francois Lafont]

Bonjour,

On 20/01/2016 09:49, Pascal Hambourg wrote:

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

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=20
rm /home/flaf/f$c
c=$((c+1))
sleep 60
done

Là, il fait comment le ramasse-miette du SSD ? Le cas 2 (données rendues
obsolètes par une écriture plus récente) ne semble jamais se produire
pour moi. Mais j'ai sûrement tort...

-- 
François Lafont

Re: Installation sur un SSD

[Pascal Hambourg]

Vincent Lefevre a écrit :
> 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é.

Re: Installation sur un SSD

[Vincent Lefevre]

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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Installation sur un SSD

[Pascal Hambourg]

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.

Fwd: Re: Installation sur un SSD

[Damien TOURDE]

Bonjour,

Voici le message que j'ai envoyé à la mauvaise personne (désolé jdd) :


 Forwarded Message 
Subject:    Re: Installation sur un SSD
Date:   Sun, 17 Jan 2016 10:59:51 +0100
From:   Damien TOURDE 
To: jdd 



Bonjour,

Le principal est de regarder avec hdparm si tu peux activer le discard,
et l'activer, ça allonge (ou raccourcis moins) la durée de vie du SSD.

De plus, noatime peut être utile pour réduire les écriture, mais il me
semble que par défaut ext4 est déjà passé au relatime, ce qui réduit
bien déjà les écritures.


Enfin très sincèrement, on fait tout un plat des SSD au niveau de la
durée de vie, mais j'ai dû sur le mien, le premier week-end, installer
mac os, pour que l'EFI veuille bien le booter, puis installer à la place
de mac une Debian, puis rapatrier mes 200Go de data.

Si je fais ça tous les 2 jours il me faudra 35 ans pour arriver aux
limites annoncées par le fabricant...


Le seul inconvénient du SSD semble être la rétention de données si non
alimenté en courant.


Damien


On 17/01/2016 08:30, jdd wrote:
> Le 16/01/2016 23:31, Benoit B a écrit :
>> Bonjour,
>>
>> Y a-t-il quelque chose de particulier à faire pour utiliser un SSD ?
>> A l'installation ?
>> Configuration (moins loguer, écritures sur le SWAP) ?
>>
>
> en ce qui me concerne je me refuse à ce genre de chose. Je compte sur
> les outils d'installation pour le faire ou sur la garantie.
>
> tous les ssd en ce moment sont garantis trois ans, et si je regarde ce
> que j'ai acheté trois ans en arrière, si les miens tombent en panne
> plus tard, je ne voudrais pas remettre les même (j'ai déjà deux 120Go,
> un 250Ggo et un 480Go :-))
>
> jdd
>
>
>

Re: Installation sur un SSD

[Sébastien NOBILI]

Le lundi 18 janvier 2016 à 15:48, Vincent Lefevre a écrit :
> On 2016-01-18 14:16:31 +0100, Sébastien NOBILI wrote:
> > Bonjour,
> > 
> > Le lundi 18 janvier 2016 à 14:06, Vincent Lefevre a écrit :
> > > On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> > > > >  - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> > > > >mémoire ou plus pour éviter des écritures inutiles.
> > > > 
> > > > /tmp/ et /var/tmp/
> > > 
> > > Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
> > > la différence avec /tmp, dont la préservation est facultative).
> > 
> > Depuis Jessie, /var/tmp/ est devenu un montage tmpfs, mais ça peut
> > bien sûr se modifier.
> 
> Non, je n'ai rien modifié, et:
> 
> zira% df /tmp
> Filesystem 1K-blocks  Used Available Use% Mounted on
> /dev/dm-1  471942448 12532 322621588  28% /
> zira% df /var/tmp
> Filesystem 1K-blocks  Used Available Use% Mounted on
> /dev/dm-1  471942448 12532 322621588  28% /
> 
> (machine installée en Jessie, puis mise à jour en unstable).

Ben oui, tu as raison. Je pensais que mon passage à Jessie avait modifié ça,
mais visiblement c'est bien moi qui avais fait la modif… amnésie…

Merci d'avoir éclairci ce point.

Sébastien

Re: Installation sur un SSD

[Vincent Lefevre]

On 2016-01-18 14:16:31 +0100, Sébastien NOBILI wrote:
> Bonjour,
> 
> Le lundi 18 janvier 2016 à 14:06, Vincent Lefevre a écrit :
> > On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> > > >  - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> > > >mémoire ou plus pour éviter des écritures inutiles.
> > > 
> > > /tmp/ et /var/tmp/
> > 
> > Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
> > la différence avec /tmp, dont la préservation est facultative).
> 
> Depuis Jessie, /var/tmp/ est devenu un montage tmpfs, mais ça peut
> bien sûr se modifier.

Non, je n'ai rien modifié, et:

zira% df /tmp
Filesystem 1K-blocks  Used Available Use% Mounted on
/dev/dm-1  471942448 12532 322621588  28% /
zira% df /var/tmp
Filesystem 1K-blocks  Used Available Use% Mounted on
/dev/dm-1  471942448 12532 322621588  28% /

(machine installée en Jessie, puis mise à jour en unstable).

Même /tmp n'est pas monté en tmpfs par défaut, comme tu peux le voir
ci-dessus et dans "/etc/default/tmpfs":

# mount /tmp as a tmpfs.  Defaults to no; set to yes to enable (/tmp
# will be part of the root filesystem if disabled).  /tmp may also be
# configured to be a separate mount in /etc/fstab.
#RAMTMP=no

Pour /var/tmp, ce n'est apparemment même pas configurable.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Installation sur un SSD

[Vincent Lefevre]

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

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Installation sur un SSD

[Vincent Lefevre]

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
  IIUU

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
  UIUU

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
  

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
  YYUU

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
  UZUU

Si une écriture doit se faire en page 2, alors le SSD peut juste
écrire dedans:

  12345678
  

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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Installation sur un SSD

[Sébastien NOBILI]

Bonjour,

Le lundi 18 janvier 2016 à 14:06, Vincent Lefevre a écrit :
> On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> > >  - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> > >mémoire ou plus pour éviter des écritures inutiles.
> > 
> > /tmp/ et /var/tmp/
> 
> Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
> la différence avec /tmp, dont la préservation est facultative).

Depuis Jessie, /var/tmp/ est devenu un montage tmpfs, mais ça peut bien sûr se
modifier.

Sébastien

Re: Installation sur un SSD

[Vincent Lefevre]

On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> >  - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> >mémoire ou plus pour éviter des écritures inutiles.
> 
> /tmp/ et /var/tmp/

Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
la différence avec /tmp, dont la préservation est facultative).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Installation sur un SSD

[Pascal Hambourg]

Christophe De Natale a écrit :
> 
> On peut lire ici ou là qu'il est nécessaire (en terme d'optimisation) de
> laisser de l'espace libre sur le ssd (donc un espace non partitionné).
> Est-ce réellement utile ?

Cela peut faciliter le ramasse-miettes et le nivellement de l'usure avec
un SSD bas de gamme qui n'a pas beaucoup d'overprovisionning (voir
réponse précédente). C'est une sorte d'overprovisionning du pauvre.

Re: Installation sur un SSD

[Pascal Hambourg]

Francois Lafont a écrit :
> 
> 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).

Exact.

> Ok, TRIM indique seulement au SSD les data qui sont devenues inutiles au fs.

Oui.

>> Au début, toutes les pages sont vides, tout va bien. On écrit donc sans
>> avoir besoin d'effacer. Quand les données d'une page doivent être
>> modifiées, on écrit les nouvelles données dans une autre page vide et on
>> marque l'ancienne page comme obsolète. C'est rapide. Au passage on devine
>> qu'il n'y a plus de correspondance entre l'adresse d'un secteur et sa
>> position physique. Si on ne fait rien, à force d'écrire et de modifier
>> les données, toutes les pages vont finir par être écrites, qu'elles
>> contiennent des données obsolètes ou actuelles. Pour continuer à écrire,
>> il va falloir effacer des blocs de pages contenant des données
>> obsolètes.
> 
> 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 ?

Il y a deux niveaux d'obsolescence des données :
- les secteurs marquées avec TRIM ;
- les pages dont les données ont été modifiées et réécrites dans une
autre page, comme décrit ci-dessus. En effet contrairement à un disque
dur les données actualisées ne sont pas écrites en place car cela
nécessiterait la copie et l'effacement préalable du bloc entier.

Pour avoir une réserve de blocs libres même si le SSD semble plein, le
SSD garde des blocs qui ne sont pas comptés dans la capacité utilisable.
Par exemple, un SSD d'une capacité utile de 120 Go aurait en réalité une
capacité 128 brute de 128 Gio (137 Go). On appelle cela
"over-provisionning".

> Ok, mais je ne vois pas comment le garbage collector du SSD va faire
> du coup pour savoir ce qui obsolète de ce qui ne l'est pas puisque j'ai
> cru comprendre qu'il ne pouvait pas le savoir sans le lancement de fstrim ?

Cf. ci-dessus. Le ramasse-miettes concerne les deux niveaux
d'obsolescence. Même sans TRIM, il reste les données obsolètes parce que
réécrites.

>> Pour que cela soit efficace il vaut mieux que le
>> système d'exploitation utilise comme unité de stockage des blocs de
>> secteurs coïncident avec une ou plusieurs pages du SSD (d'où les
>> contraintes nouvelles d'alignement des partitions),
> 
> Si je fais commencer mes partitions à 1MiB, suis-je à l'abri de problèmes 
> d'alignement ?

J'ai lu que certains SSD auraient une taille de bloc d'effacement
supérieure, de 2 Mio. Mais ce qui compte c'est surtout l'alignement avec
les pages du SSD, dont la taille maximum semble être 8 Kio. Idéalement
il faudrait donc dans ce cas utiliser en plus une taille de bloc égale
ou multiple. Or la taille de bloc par défaut des systèmes de fichiers
est souvent 4 Kio.

>> Le TRIM en lui-même ne fait que marquer les données obsolètes, il
>> n'efface rien. Un firmware de SSD bien conçu ne devrait pas déclencher
>> le ramasse-miette en fonction de la fréquence du TRIM mais seulement en
>> fonction du nombre de blocs libres et du taux d'écriture.
> 
> Ok, mais alors comme ça a été dit dans un message précédent, il est recommandé
> de faire un fstrim une fois par semaine, c'est ça ?

Je n'ai pas d'avis ni d'expérience sur la question. En toute rigueur,
cela dépend de l'utilisation, en combien de temps la vitesse d'écriture
commence à baisser sans TRIM.

> Je n'arrive plus à retrouver le lien probant mais il me semble bien avoir lu
> quelque part que faire un fstrim de temps en temps n'était pas nécessaire sur
> certains disques SSD, est-ce vrai ? Par exemple (certes ce n'est pas très 
> probant
> comme lien), ici 
> http://www.mail-archive.com/ceph-users%40lists.ceph.com/msg12756.html
> un admin écrit :
> 
> « Of course if you're using Intel DC 3700S SSDs you probably won't get any
> speed benefit from this at least, they're never slowing down. ^^ »

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.

> On est d'accord que fstrim est valable uniquement pour des partitions avec
> file system, n'est-ce pas ? Par exemple si une application utilise un 
> partition
> brute sans file system (je pense à Ceph par exemple qui utilise des partitions
> brutes où il écrit de manière séquentielle dessus), alors le fstrim n'y est 
> pas né

Re: Installation sur un SSD

[Christophe De Natale]

Le dimanche 17 janvier 2016 à 20:41 +0100, Pascal Hambourg a écrit :
> Francois Lafont a écrit :
> > 
> > Mais alors, si jamais on monte un disque SSD sans l'option discard _et_ sans
> > prendre le soin de faire un fstrim régulièrement, alors que se passe-t-il ?
> > Le disque va se remplir inexorablement au fil du temps
> 
> Oui, en quelque sorte.
> 
> > et à un moment donné je ne pourrai tout simplement plus écrire dessus
> 
> Non, quand même pas. Mais les écritures seront beaucoup plus coûteuses.
> 
> > Personnellement, j'aurais plutôt pensé que le SSD fait le trim lui-même tout
> > seul comme un grand, quand ça l'arrange.
> 
> 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.
> 
> > En fait, je pensais même que le discard ou le fstrim auraient même tendance 
> > à
> > diminuer la durée de vie du SSD vu que ça l'oblige à effacer des cellules à 
> > un
> > moment où, peut-être, ce n'est pas nécessaire.
> 
> Rien n'oblige le SSD a effacer immédiatement suite à une commande TRIM.
> 
> Un peu d'explication.
> 
> Bien que la finalité soit la même, un SSD fonctionne très différemment
> d'un disque dur.
> 
> Un disque dur est divisé en secteurs indépendants les uns des autres (à
> l'exception des disques au format avancé 512e où plusieurs secteurs
> logiques sont regroupés dans un secteur physique, mais on va faire
> l'impasse). Chaque secteur a un contenu (que ce soit des zéros ou autre
> chose n'a pas d'importance) et la modification de ce contenu se fait
> simplement en écrivant par dessus, comme une bande magnétique. Il y a
> une correspondance entre l'adresse logique d'un secteur et sa position
> physique sur le disque (à l'exception des secteurs défectueux qui ont
> été réalloués).
> 
> Un SSD est très différent. Les secteurs ne sont pas indépendants : ils
> sont regroupés en pages (typiquement 4 ou 8 Kio), et les pages sont
> regroupées en blocs d'effacement (typiquement 1 Mio). L'écriture ne peut
> se faire que sur une page entière, mais il y a pire : on ne peut écrire
> que dans une page préalablement effacée. On ne peut pas réécrire
> directement par dessus une page qui a déjà été écrite, il faut d'abord
> effacer tout le bloc qui la contient. Or l'effacement d'un bloc est une
> opération coûteuse, en temps et en usure des cellules.
> 
> C'est un peu comme écrire au crayon sur une feuille de papier : pour
> réécrire au même endroit, il faut d'abord effacer à la gomme, ce qui use
> le papier. A la longue, à force de gommer un emplacement, le papier
> devient trop usé et inutilisable.
> 
> Au début, toutes les pages sont vides, tout va bien. On écrit donc sans
> avoir besoin d'effacer. Quand les données d'une page doivent être
> modifiées, on écrit les nouvelles données dans une autre page vide et on
> marque l'anciene page comme obsolète. C'est rapide. Au passage on devine
> qu'il n'y a plus de correspondance entre l'adresse d'un secteur et sa
> position physique. Si on ne fait rien, à force d'écrire et de modifier
> les données, toutes les pages vont finir par être écrites, qu'elles
> contiennent des données obsolètes ou actuelles. Pour continuer à écrire,
> il va falloir effacer des blocs de pages contenant des données
> obsolètes. Si toutes les pages d'un bloc contiennent des données
> obsolètes, il suffit d'effacer le bloc. Mais si certaines pages du bloc
> contiennent des données actuelles, il faut les copier dans une mémoire
> tampon, effacer le bloc et réécrire les données.
> 
> On ne peut pas faire ça à chaque nouvelle écriture, ce serait trop
> coûteux en temps et en usure. Pour éviter cette situation, le SSA
> procède régulièrement à un "ramasse-miettes" (garbage collection). Cela
> consiste à transférer les données des pages actuelles dans de nouveaux
> blocs et d'effacer les anciens blocs. Le but est de toujours disposer de
> suffisamment de pages vides d'avance pour que l'écriture reste rapide.
> Il ne faut pas le faire trop souvent non plus car, comme tout
> effacement, cela augmente l'usure.
> 
> C'est notamment ici que le TRIM intervient : en marquant des secteurs
> comme obsolètes lors de l'effacement d'un fichier, il facilite le
> ramasse-miettes. Pour que cela soit efficace il vaut mieux que le
> système d'exploitation utilise comme unité de stockage des blocs de
> secteurs coïncident avec une ou plusieurs pages du SSD (d'où les
> contraintes nouvelles d'alignement des partitions), ainsi tous les
> secteurs d'une page seront marqués en même temps et la page pourra être
> écartée.
> 
> Le TRIM en lui-même ne fait que marquer les données obsolètes, il
> n'efface rien. Un firmware de SSD bien conçu ne devrait pas déclencher
> le ramasse-miette en fonction de la fréquence du TRIM mais seulement en
> fonction du nombre de blocs libres et du taux d'écriture.
> 

Bonjour et merci

Re: Installation sur un SSD

[Francois Lafont]

Déjà merci Sébastien et Pascal pour toutes ces explications.

On 17/01/2016 20:41, Pascal Hambourg wrote:

>> Mais alors, si jamais on monte un disque SSD sans l'option discard _et_ sans
>> prendre le soin de faire un fstrim régulièrement, alors que se passe-t-il ?
>> Le disque va se remplir inexorablement au fil du temps
> 
> Oui, en quelque sorte.
> 
>> et à un moment donné je ne pourrai tout simplement plus écrire dessus
> 
> Non, quand même pas. Mais les écritures seront beaucoup plus coûteuses.
> 
>> Personnellement, j'aurais plutôt pensé que le SSD fait le trim lui-même tout
>> seul comme un grand, quand ça l'arrange.
> 
> 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).

>> En fait, je pensais même que le discard ou le fstrim auraient même tendance à
>> diminuer la durée de vie du SSD vu que ça l'oblige à effacer des cellules à 
>> un
>> moment où, peut-être, ce n'est pas nécessaire.
> 
> 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.

> Bien que la finalité soit la même, un SSD fonctionne très différemment
> d'un disque dur.
> 
> Un disque dur est divisé en secteurs indépendants les uns des autres (à
> l'exception des disques au format avancé 512e où plusieurs secteurs
> logiques sont regroupés dans un secteur physique, mais on va faire
> l'impasse). Chaque secteur a un contenu (que ce soit des zéros ou autre
> chose n'a pas d'importance) et la modification de ce contenu se fait
> simplement en écrivant par dessus, comme une bande magnétique. Il y a
> une correspondance entre l'adresse logique d'un secteur et sa position
> physique sur le disque (à l'exception des secteurs défectueux qui ont
> été réalloués).
> 
> Un SSD est très différent. Les secteurs ne sont pas indépendants : ils
> sont regroupés en pages (typiquement 4 ou 8 Kio), et les pages sont
> regroupées en blocs d'effacement (typiquement 1 Mio). L'écriture ne peut
> se faire que sur une page entière, mais il y a pire : on ne peut écrire
> que dans une page préalablement effacée. On ne peut pas réécrire
> directement par dessus une page qui a déjà été écrite, il faut d'abord
> effacer tout le bloc qui la contient. Or l'effacement d'un bloc est une
> opération coûteuse, en temps et en usure des cellules.
> 
> C'est un peu comme écrire au crayon sur une feuille de papier : pour
> réécrire au même endroit, il faut d'abord effacer à la gomme, ce qui use
> le papier. A la longue, à force de gommer un emplacement, le papier
> devient trop usé et inutilisable.
> 
> Au début, toutes les pages sont vides, tout va bien. On écrit donc sans
> avoir besoin d'effacer. Quand les données d'une page doivent être
> modifiées, on écrit les nouvelles données dans une autre page vide et on
> marque l'ancienne page comme obsolète. C'est rapide. Au passage on devine
> qu'il n'y a plus de correspondance entre l'adresse d'un secteur et sa
> position physique. Si on ne fait rien, à force d'écrire et de modifier
> les données, toutes les pages vont finir par être écrites, qu'elles
> contiennent des données obsolètes ou actuelles. Pour continuer à écrire,
> il va falloir effacer des blocs de pages contenant des données
> obsolètes.

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 ?

> Si toutes les pages d'un bloc contiennent des données
> obsolètes, il suffit d'effacer le bloc. Mais si certaines pages du bloc
> contiennent des données actuelles, il faut les copier dans une mémoire
> tampon, effacer le bloc et réécrire les données.
> 
> On ne peut pas faire ça à chaque nouvelle écriture, ce serait trop
> coûteux en temps et en usure. Pour éviter cette situation, le SSA
> procède régulièrement à un "ramasse-miettes" (garbage collection). Cela
> consiste à transférer les données des pages actuelles dans de nouveaux
> blocs et d'effacer les anciens blocs. Le but est de toujours disposer de
> suffisamment de pages vides d'avance pour que l'écriture reste rapide.
> Il ne faut pas le faire trop souvent non plus car, comme tout
> effacement, cela augmente l'usure.

Ok, mais je ne vois pas comment le garbage collector du SSD va faire
du coup pour savoir ce qui obsolète de ce qui ne l'est pas

Re: Installation sur un SSD

[Pascal Hambourg]

Francois Lafont a écrit :
> 
> Mais alors, si jamais on monte un disque SSD sans l'option discard _et_ sans
> prendre le soin de faire un fstrim régulièrement, alors que se passe-t-il ?
> Le disque va se remplir inexorablement au fil du temps

Oui, en quelque sorte.

> et à un moment donné je ne pourrai tout simplement plus écrire dessus

Non, quand même pas. Mais les écritures seront beaucoup plus coûteuses.

> Personnellement, j'aurais plutôt pensé que le SSD fait le trim lui-même tout
> seul comme un grand, quand ça l'arrange.

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.

> En fait, je pensais même que le discard ou le fstrim auraient même tendance à
> diminuer la durée de vie du SSD vu que ça l'oblige à effacer des cellules à un
> moment où, peut-être, ce n'est pas nécessaire.

Rien n'oblige le SSD a effacer immédiatement suite à une commande TRIM.

Un peu d'explication.

Bien que la finalité soit la même, un SSD fonctionne très différemment
d'un disque dur.

Un disque dur est divisé en secteurs indépendants les uns des autres (à
l'exception des disques au format avancé 512e où plusieurs secteurs
logiques sont regroupés dans un secteur physique, mais on va faire
l'impasse). Chaque secteur a un contenu (que ce soit des zéros ou autre
chose n'a pas d'importance) et la modification de ce contenu se fait
simplement en écrivant par dessus, comme une bande magnétique. Il y a
une correspondance entre l'adresse logique d'un secteur et sa position
physique sur le disque (à l'exception des secteurs défectueux qui ont
été réalloués).

Un SSD est très différent. Les secteurs ne sont pas indépendants : ils
sont regroupés en pages (typiquement 4 ou 8 Kio), et les pages sont
regroupées en blocs d'effacement (typiquement 1 Mio). L'écriture ne peut
se faire que sur une page entière, mais il y a pire : on ne peut écrire
que dans une page préalablement effacée. On ne peut pas réécrire
directement par dessus une page qui a déjà été écrite, il faut d'abord
effacer tout le bloc qui la contient. Or l'effacement d'un bloc est une
opération coûteuse, en temps et en usure des cellules.

C'est un peu comme écrire au crayon sur une feuille de papier : pour
réécrire au même endroit, il faut d'abord effacer à la gomme, ce qui use
le papier. A la longue, à force de gommer un emplacement, le papier
devient trop usé et inutilisable.

Au début, toutes les pages sont vides, tout va bien. On écrit donc sans
avoir besoin d'effacer. Quand les données d'une page doivent être
modifiées, on écrit les nouvelles données dans une autre page vide et on
marque l'anciene page comme obsolète. C'est rapide. Au passage on devine
qu'il n'y a plus de correspondance entre l'adresse d'un secteur et sa
position physique. Si on ne fait rien, à force d'écrire et de modifier
les données, toutes les pages vont finir par être écrites, qu'elles
contiennent des données obsolètes ou actuelles. Pour continuer à écrire,
il va falloir effacer des blocs de pages contenant des données
obsolètes. Si toutes les pages d'un bloc contiennent des données
obsolètes, il suffit d'effacer le bloc. Mais si certaines pages du bloc
contiennent des données actuelles, il faut les copier dans une mémoire
tampon, effacer le bloc et réécrire les données.

On ne peut pas faire ça à chaque nouvelle écriture, ce serait trop
coûteux en temps et en usure. Pour éviter cette situation, le SSA
procède régulièrement à un "ramasse-miettes" (garbage collection). Cela
consiste à transférer les données des pages actuelles dans de nouveaux
blocs et d'effacer les anciens blocs. Le but est de toujours disposer de
suffisamment de pages vides d'avance pour que l'écriture reste rapide.
Il ne faut pas le faire trop souvent non plus car, comme tout
effacement, cela augmente l'usure.

C'est notamment ici que le TRIM intervient : en marquant des secteurs
comme obsolètes lors de l'effacement d'un fichier, il facilite le
ramasse-miettes. Pour que cela soit efficace il vaut mieux que le
système d'exploitation utilise comme unité de stockage des blocs de
secteurs coïncident avec une ou plusieurs pages du SSD (d'où les
contraintes nouvelles d'alignement des partitions), ainsi tous les
secteurs d'une page seront marqués en même temps et la page pourra être
écartée.

Le TRIM en lui-même ne fait que marquer les données obsolètes, il
n'efface rien. Un firmware de SSD bien conçu ne devrait pas déclencher
le ramasse-miette en fonction de la fréquence du TRIM mais seulement en
fonction du nombre de blocs libres et du taux d'écriture.

Re: Installation sur un SSD

[jdd]

Le 17/01/2016 20:24, Eddy F. a écrit :

/sbin/fstrim /


moins d'une minute sur mon ssd de 480Go, mais ca ne veut rien dire car 
il n'y avait sans doute pas grand chose à trimmer.


mais pourquoi se faire du souci? il suffit de le faire si on sent un 
ralentissement...


et pas trop souvent, ca ne semble pas indolore (voir la page de man)

jdd

Re: Installation sur un SSD

[Eddy F.]

Le 17 jan 2016 à 19:57 (+0100)
Sébastien Dinot  a écrit:
 
> Je ne sais pas si l'interruption de fstrim est ravageuse ou pas (je ne
> le pense pas vu ce qu'elle fait) mais s'il s'agit de te rassurer, tu
> peux la lancer à la main :
> 
> sudo /sbin/fstrim /

Oui mais le faire manuellement est le meilleur moyen pour que ce ne
soit jamais fait ! (Enfin, je parle pour moi.)

> Sur mon poste, son exécution prend une poignée de minutes (5 tout au
> plus) mais mon SSD a une taille de 64 Go seulement et je subodore que
> la durée de l'opération est proportionnelle à la taille du disque.

Oui, je viens de tester sur mon SSD de 60 Go et cela a pris une grosse
minute. C'est pour cela que le risque semble bien faible de toute
façon.


-- 
Eddy F.

Re: Installation sur un SSD

[Sébastien Dinot]

Eddy F. a écrit :
> Si quelqu'un peut me rassurer :-)

Je ne sais pas si l'interruption de fstrim est ravageuse ou pas (je ne
le pense pas vu ce qu'elle fait) mais s'il s'agit de te rassurer, tu
peux la lancer à la main :

sudo /sbin/fstrim /

Sur mon poste, son exécution prend une poignée de minutes (5 tout au
plus) mais mon SSD a une taille de 64 Go seulement et je subodore que la
durée de l'opération est proportionnelle à la taille du disque.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: Installation sur un SSD

[Eddy F.]

Le 17 jan 2016 à 14:21 (+0100)
Sébastien Dinot  a écrit:


> En outre, à ma connaissance, l'option discard a plutôt un effet
> négatif sur les performances. Cf. le point 3 de l'article ci-dessous :
> 
> http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/
> 
> Je lui préfère donc, comme cela est préconisé dans l'article, un petit
> « /sbin/fstrim / » lancé via cron.

J'ai une question naïve, ne m'en voulez-pas.

Que se passe-t-il si la commande fstrim est interrompue avant d'avoir
fait son travail ? Je pense au fait que si la tâche est lancée par
cron, il y a un risque (sans doute très faible) que j'éteigne la
machine juste au moment où elle s'exécute. Est-que cela risque de
corrompre le système de fichier (je suppose que non si j'ai bien
compris à quoi sert le fstrim) ou d'endommager le disque ?

Si quelqu'un peut me rassurer :-)

-- 
Eddy F.

Re: Installation sur un SSD

[jdd]

Le 17/01/2016 18:43, Erwan David a écrit :


On a déjà des SSD de 4 et 6 To, voire même de 13To (mais sur controlleur
proprio pour ces derniers et compter ~ 1000 $ HT du To)

je commence à regarder en dessous de cent euros... à peu près (je viens 
d'acheter deux disques usb de 5To pour mes archives, à 140 euros pièce 
chez Nierle)


jdd

Re: Installation sur un SSD

[Erwan David]

Le 17/01/2016 18:39, jdd a écrit :
> Le 17/01/2016 14:54, andre_deb...@numericable.fr a écrit :
>> On Sunday 17 January 2016 13:36:46 C. Mourad Jaber wrote:
>>> 
>>> Les SSD sont très bien gérés par le système.
>>
>> sauf lorsqu'ils tombent en rade, les SSD n'apprécient guère
>> trop d'écritures.
>>
>> André
>>
> as-tu une expérience personnelle de la destruction d'un ssd?
>
> perso je n'en ai pas encore. Entre les avancées de la technologie et
> celles du noyau, j'ai choisi de ne m'occuper de rien, certain que le
> noyau (et ses programmeurs) sont bien plus compétents que moi.
>
> Si la baisse des prix des ssd suit celle des clés usb, dans trois ans
> on aura des ssd de 2To et il y a longtemps que mes ssd actuels seront
> aux oubliettes. J'ai déjà un ssd de 120 Go à peu près inutilisé (et
> qui ne doit ps avoir deux ans), et un de 250Go en passe de ne plus
> servir...
>
> jdd
>
>

On a déjà des SSD de 4 et 6 To, voire même de 13To (mais sur controlleur
proprio pour ces derniers et compter ~ 1000 $ HT du To)

Re: Installation sur un SSD

[jdd]

Le 17/01/2016 14:54, andre_deb...@numericable.fr a écrit :

On Sunday 17 January 2016 13:36:46 C. Mourad Jaber wrote:


Les SSD sont très bien gérés par le système.


sauf lorsqu'ils tombent en rade, les SSD n'apprécient guère
trop d'écritures.

André


as-tu une expérience personnelle de la destruction d'un ssd?

perso je n'en ai pas encore. Entre les avancées de la technologie et 
celles du noyau, j'ai choisi de ne m'occuper de rien, certain que le 
noyau (et ses programmeurs) sont bien plus compétents que moi.


Si la baisse des prix des ssd suit celle des clés usb, dans trois ans on 
aura des ssd de 2To et il y a longtemps que mes ssd actuels seront aux 
oubliettes. J'ai déjà un ssd de 120 Go à peu près inutilisé (et qui ne 
doit ps avoir deux ans), et un de 250Go en passe de ne plus servir...


jdd

Re: Installation sur un SSD

[Pascal Hambourg]

Sébastien Dinot a écrit :
> 
> L'avantage du tmpfs sur les ramdisks traditionnels est qu'il ne consomme
> que la mémoire nécessaire avec un plafond fixé à 50 % de la mémoire vive
> disponible.

Bien que ce soit un peu hors sujet dans ce fil, je voudrais nuancer à
cette affirmation.

D'abord un petit rappel sur la différence fondamentale entre ramdisk et
tmpfs : un ramdisk est un périphérique bloc, comme un disque physique,
une partition, un ensemble RAID, un volume logique LVM, un volume
chiffré... On peut y mettre n'importe quel contenu ; système de fichiers
de type quelconque, swap (pas grand intérêt certes), données brutes...
Il existe indépendamment de son utilisation. Un tmpfs est uniquement un
système de fichiers, sans périphérique sous-jacent, et n'existe que s'il
est monté.

Un ramdisk traditionnel, comme un tmpfs, ne consomme pas de mémoire tant
qu'on n'a pas écrit dedans. Néanmoins une fois qu'un bloc a été écrit,
il occupe de la mémoire même s'il n'est plus utilisé par la suite (par
exemple s'il contenait un fichier effacé). Au contraire, quand un
fichier d'un tmpfs est effacé, la mémoire qu'il occupait est libérée.

Autre avantage du tmpfs : en cas de pression sur la mémoire, son contenu
peut être swappé. On peut donc définir un tmpfs de grande taille sans
craindre l'épuisement de la mémoire tant qu'il y a assez de swap.

Lorsqu'on veut utiliser un système de fichiers en mémoire, il semble
donc que tmpfs n'ait que des avantages par rapport à un système de
fichiers traditionnel dans un ramdisk. Mais une nouvelle variante de
ramdisk est disponible à partir noyau 3.14 : zram. Grâce à la
compression, l'occupation de la mémoire est réduite en fonction de la
nature des données. Autres avantages : un zram peut être réinitialisé ou
désactivé, libérant toute la mémoire qu'il occupait, et supporte la
notification de libération (en d'autres termes, l'option "discard" ou
l'utilisation de "fstrim" pour libérer la mémoire occupée par les
fichiers supprimés).

Re: Installation sur un SSD

[Sébastien Dinot]

Francois Lafont a écrit :
> Mais alors, si jamais on monte un disque SSD sans l'option discard
> _et_ sans prendre le soin de faire un fstrim régulièrement, alors que
> se passe-t-il ? Le disque va se remplir inexorablement au fil du temps
> et à un moment donné je ne pourrai tout simplement plus écrire dessus
> (bien que le filesystem, lui, ne soit pas à 100%) ?

Je ne suis nullement un spécialiste de la question mais ma compréhension
du fonctionnement de la commande TRIM est qu'elle marque les blocs
disponibles en réinitialisant au passage leur contenu.

Si on ne l'exécute pas de temps à autres, d'une part les performances du
SSD se dégradent petit à petit (j'ai pu le constater avant de découvrir
cette commande) et d'autre part, lorsque le contrôleur fini par avoir
besoin d'espace, il doit se livrer à de coûteux cycles de
lecture/effacement/écriture.

> Personnellement, j'aurais plutôt pensé que le SSD fait le trim
> lui-même tout seul comme un grand, quand ça l'arrange. Je me trompe ?
> Ou alors ce n'est vrai que pour des SSD d'une certaine qualité ?

Si j'ai là encore bien compris le nœud du problème, le contrôleur SSD
n'a pas plus d'idée de la signification du contenu des blocs que le
contrôleur RAM n'a d'idée du contenu des blocs de mémoire vive. Du coup,
il ne peut déterminer lui-même quels sont les blocs libres, tout comme
le contrôleur de mémoire vive ne peut pas détecter qu'un bloc réservé
par une application n'est plus utilisé par cette application et décider
de réutiliser ce bloc. Dans les deux cas, c'est au système
d'exploitation d'agir car c'est à son niveau que la donnée prend son
sens technique et devient une information.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: Installation sur un SSD

[Francois Lafont]

Bonjour,

On 17/01/2016 14:21, Sébastien Dinot wrote:

> En outre, à ma connaissance, l'option discard a plutôt un effet négatif
> sur les performances. Cf. le point 3 de l'article ci-dessous :
> 
> http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/
> 
> Je lui préfère donc, comme cela est préconisé dans l'article, un petit
> « /sbin/fstrim / » lancé via cron.

Merci pour ces infos mais du coup j'aurais des questions sur discard car en
fait je ne pige pas trop l'intérêt de option ni même du /sbin/fstrim. Dans
le lien que tu donnes, on peut lire au tout début « NAND flash memory that
make SSD cannot overwrite existing data ».

Mais alors, si jamais on monte un disque SSD sans l'option discard _et_ sans
prendre le soin de faire un fstrim régulièrement, alors que se passe-t-il ?
Le disque va se remplir inexorablement au fil du temps et à un moment donné
je ne pourrai tout simplement plus écrire dessus (bien que le filesystem, lui,
ne soit pas à 100%) ? Auquel cas je trouverai un peu vache.

Personnellement, j'aurais plutôt pensé que le SSD fait le trim lui-même tout
seul comme un grand, quand ça l'arrange. Je me trompe ? Ou alors ce n'est vrai
que pour des SSD d'une certaine qualité ?

En fait, je pensais même que le discard ou le fstrim auraient même tendance à
diminuer la durée de vie du SSD vu que ça l'oblige à effacer des cellules à un
moment où, peut-être, ce n'est pas nécessaire.

Bref, si vous avez des explications sur tout ça, je serais vraiment très 
intéressé
car j'ai personnellement des serveurs (pas beaucoup) qui utilisent des SSD et
j'avoue que je ne me suis jamais préoccupé de cette option discard et/ou du 
fstrim
(pour info les SSD sont des Intel Series 3710 200GB).

Merci d'avance pour vos lumières (j'espère ne pas trop sortir du sujet de ce 
fil).

-- 
François Lafont

Re: Installation sur un SSD

[andre_debian]

On Sunday 17 January 2016 13:36:46 C. Mourad Jaber wrote:
> 
> Les SSD sont très bien gérés par le système.

sauf lorsqu'ils tombent en rade, les SSD n'apprécient guère
trop d'écritures.

André

Re: Installation sur un SSD

[Sébastien Dinot]

Bonjour,

C. Mourad Jaber a écrit :
>  - les options "discard,noatime,nodiratime" sur les montages
>"utilisateur" (home directory),

Pourquoi limiter ces options à /home ?

L'option noatime implique l'option nodiratime. Préciser la seconde est
donc inutile quand on indique la première. Depuis la version 2.6.30, le
noyau Linux ne monte pas par défaut les partitions avec l'option
« atime » mais avec l'option « relatime » (cf. /etc/mtab), ce qui ménage
la chèvre et le chou.

En outre, à ma connaissance, l'option discard a plutôt un effet négatif
sur les performances. Cf. le point 3 de l'article ci-dessous :

http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/

Je lui préfère donc, comme cela est préconisé dans l'article, un petit
« /sbin/fstrim / » lancé via cron.

>  - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
>mémoire ou plus pour éviter des écritures inutiles.

/tmp/ et /var/tmp/

L'avantage du tmpfs sur les ramdisks traditionnels est qu'il ne consomme
que la mémoire nécessaire avec un plafond fixé à 50 % de la mémoire vive
disponible. Or, l'expérience montre que la plupart du temps, le
répertoire /tmp contient moins de quelques dizaines de Mo de données,
même sur les serveurs multi-utilisateurs.

> Si tu as un 2eme disque à plateau classique, tu peux mettre /tmp /home
> /var dessus, mais tu n'auras pas un amélioration aussi spectaculaire
> des performances...

Monter les répertoires /tmp et /var sur un disque à plateau va en effet
pénaliser le système. Pour /home, je suis persuadé que l'impact ne se
perçoit pas au niveau utilisateur (en tout cas, c'est mon ressenti
personnel).

Pour ma part, j'utilise un disque dur à plateau pour monter les
répertoires /home et /var/log :

- /home ne contient que des fichiers de données et si l'on considère les
  utilisations les plus courantes, je ne vois pas ce qu'un SSD apporte.
  Un SSD n'est pertinent que lorsque la rapidité des entrées/sorties
  fait la performance d'une application (chargement des binaires,
  compilation, base de données, etc.). Pour lire un fichier MP3 ou DIVX
  ou surfer sur le net, le SSD est superflu.

- /var/log contient des fichiers de logs qui sont le plus souvent
  l'œuvre de syslog, démon asynchrone qui ne pénalise pas les
  applications qui lui transmettent les logs.

Ceci étant, j'ai opté pour cette configuration à l'époque où les disques
SSD coûtaient un bras et où je m'étais contenté d'un petit SSD de 64 Go.
L'année dernière, j'ai remplacé le disque à plateau d'un portable par un
disque SSD de 240 Go, cela suffit à mon bonheur.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: Installation sur un SSD

[Pascal Hambourg]

Benoit B a écrit :
> 
> Pas de bol ! :(
> https://wiki.debian.org/SSDOptimization#WARNING
> 
> Pour mon Samsung SSD 850 EVO
> 
> /* devices that don't properly handle queued TRIM commands */
> 
>   { "Samsung SSD 8*", NULL,   ATA_HORKAGE_NO_NCQ_TRIM |
>   ATA_HORKAGE_ZERO_AFTER_TRIM, },
> 
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4268
> 
> Cela veut-il dire que je ne vais pas pouvoir activer la commande TRIM (
> *Discard)* avec ce modèle de disque ? :(

Non, sauf erreur ça veut dire que lors de l'effacement d'un fichier
l'option "discard" ne pourra pas utiliser la nouvelle commande TRIM
"queued" mais seulement l'ancienne commande TRIM "non queued", qui a
pour inconvénient d'interrompre les opérations de lecture/écriture en
cours et d'empêcher toute nouvelle opération avant la fin de son
exécution, qui peut être longue. C'est pourquoi certains recommandent de
ne pas utiliser l'option de montage "discard" mais d'effectuer un TRIM
périodique avec la commande "fstrim".

Re: Installation sur un SSD

[Benoit B]

Le 17 janvier 2016 à 13:36, C. Mourad Jaber  a écrit :
>
> Bonjour,
>
> J'ai plusieurs systèmes sur des SSD depuis 3 ou 4 ans maintenant, pas de 
> choses particulières mise à part des trucs très lights :
>  - les options "discard,noatime,nodiratime" sur les montages "utilisateur" 
> (home directory),
>  - le répertoire /tmp monté en tmpfs pour les machines de 8Go de mémoire ou 
> plus pour éviter des écritures inutiles.
>
> Les SSD sont très bien gérés par le système.
>

Et pour l'option "discard" avec mon disque(Samsung SSD 8*) quelqu'un
as des infos ?
https://wiki.debian.org/SSDOptimization#WARNING

J'ai peur d'avoir fais un mauvais choix...

>
> En général, ils sont garantie 3 ans dans une utilisation assez important 
> (écriture de + de 20% du disque par jour soit une 3-4 écriture complète du 
> disque / mois), ceci n'arrive pas en pratique sur des ordinateurs de bureau...
>

Je devrai peut-être me rabattre là dessus ?

> Si tu as un 2eme disque à plateau classique, tu peux mettre /tmp /home /var 
> dessus, mais tu n'auras pas un amélioration aussi spectaculaire des 
> performances...
>
Non c'est un portable, une seule place et pas de M2 pour laisser un
disque à plateau classique.

Merci d'avance.

--
Benoit

Re: Installation sur un SSD

[Benoit B]

Bonjour,

Merci pour cette réponse avec un lien si précis.

Le 16 janvier 2016 à 23:54, Bernard Schoenacker bonjour,

>
> voici un tuto presque complet ayant trait à la question :
>
>
> http://www.dmesg.fr/gestion-hardware/144-optimiser-un-disque-dur-ssd-sous-debian-linux-mint-ubuntu-et-derives
>
> https://wiki.debian.org/SSDOptimization


Pas de bol ! :(
https://wiki.debian.org/SSDOptimization#WARNING

Pour mon Samsung SSD 850 EVO

/* devices that don't properly handle queued TRIM commands */

{ "Samsung SSD 8*", NULL,   ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },


https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4268

Cela veut-il dire que je ne vais pas pouvoir activer la commande TRIM (
*Discard)* avec ce modèle de disque ? :(

Merci d'avane.

Benoit

Re: Installation sur un SSD

[C. Mourad Jaber]

Le 16/01/2016 23:31, Benoit B a écrit :

Bonjour,

Y a-t-il quelque chose de particulier à faire pour utiliser un SSD ?
A l'installation ?
Configuration (moins loguer, écritures sur le SWAP) ?

Merci d'avance

--
Benoit

Bonjour,

J'ai plusieurs systèmes sur des SSD depuis 3 ou 4 ans maintenant, pas de choses 
particulières mise à part des trucs très lights :

 - les options "discard,noatime,nodiratime" sur les montages "utilisateur" 
(home directory),
 - le répertoire /tmp monté en tmpfs pour les machines de 8Go de mémoire ou plus pour 
éviter des écritures inutiles.


Les SSD sont très bien gérés par le système.

En général, ils sont garantie 3 ans dans une utilisation assez important (écriture de + de 
20% du disque par jour soit une 3-4 écriture complète du disque / mois), ceci n'arrive pas 
en pratique sur des ordinateurs de bureau...


Si tu as un 2eme disque à plateau classique, tu peux mettre /tmp /home /var dessus, mais 
tu n'auras pas un amélioration aussi spectaculaire des performances...


Mes 2 cents...

Mourad

Re: Installation sur un SSD

[jdd]

Le 16/01/2016 23:31, Benoit B a écrit :

Bonjour,

Y a-t-il quelque chose de particulier à faire pour utiliser un SSD ?
A l'installation ?
Configuration (moins loguer, écritures sur le SWAP) ?



en ce qui me concerne je me refuse à ce genre de chose. Je compte sur 
les outils d'installation pour le faire ou sur la garantie.


tous les ssd en ce moment sont garantis trois ans, et si je regarde ce 
que j'ai acheté trois ans en arrière, si les miens tombent en panne plus 
tard, je ne voudrais pas remettre les même (j'ai déjà deux 120Go, un 
250Ggo et un 480Go :-))


jdd

Re: Installation sur un SSD

[Bernard Schoenacker]

Le Sat, 16 Jan 2016 23:31:40 +0100,
Benoit B  a écrit :

> Bonjour,
> 
> Y a-t-il quelque chose de particulier à faire pour utiliser un SSD ?
> A l'installation ?
> Configuration (moins loguer, écritures sur le SWAP) ?
> 
> Merci d'avance
> 
> --
> Benoit

bonjour,

voici un tuto presque complet ayant trait à la question :

http://www.dmesg.fr/gestion-hardware/144-optimiser-un-disque-dur-ssd-sous-debian-linux-mint-ubuntu-et-derives

https://wiki.debian.org/SSDOptimization
https://wiki.debian.org/SSD%20Installation

slt
bernard

Installation sur un SSD

[Benoit B]

Bonjour,

Y a-t-il quelque chose de particulier à faire pour utiliser un SSD ?
A l'installation ?
Configuration (moins loguer, écritures sur le SWAP) ?

Merci d'avance

--
Benoit