Installation sur un SSD

Le 17/01/2016 14:54, andre_debian@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

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

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

Le 17/01/2016 18:39, jdd a écrit :

Le 17/01/2016 14:54, andre_debian@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)

Le 17 jan 2016 à 14:21 (+0100)
Sébastien Dinot <sebastien.dinot@free.fr> 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.

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.dinot@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Le 17 jan 2016 à 19:57 (+0100)
Sébastien Dinot <sebastien.dinot@free.fr> 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.

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

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.

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 puisque j'ai
cru comprendre qu'il ne pouvait pas le savoir sans le lancement de fstrim ?

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.

Il facilite mais sans le lancement de fstrim, comment fait 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),

Si je fais commencer mes partitions à 1MiB, suis-je à l'abri de problèmes d'alignement ?

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.

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'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. ^^ »

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écessaire ?

Merci encore Pascal pour toutes ces explications vraiment intéressantes.

--
François Lafont