Disque Dur SSD

Le 25/01/2019 à 08:56, aishen a écrit :

Pas seulement, au début linux/unix on mettait de la swap pour avoir une
mémoire disque plus rapide, donc le ssd était presque de la RAM,

Pardon ?
"De la swap pour avoir une mémoire disque plus rapide", qu'est-ce que ça
veut dire ?
Un SSD aux débuts de Linux/Unix ?

chacun fait ce qu'il veut mais ne devrait pas être traité
d'absurde ou idiot

Qui a été traité d'absurde ou d'idiot dans cette discussion ?

Le 25/01/2019 à 08:38, Daniel Caillibaud a écrit :

Le 25/01/19 à 07:35, aishen <aishen@free.fr> a écrit :

on n'a pas besoin de swap sur un ssd linux,

????
Quel rapport entre le besoin de swap (manque de RAM du système) et la
nature du disque ?

d'après les avis il est
même déconseillé d'en mettre pour éviter des lectures/écritures
constantes qui "usent" la mémoire des ssd

La lecture n'use pas les SSD. Et avoir un swap n'implique pas qu'il va y
avoir des écritures constantes. Au contraire cela peut diminuer le
volume d'écritures par une meilleure gestion des caches disque.

La situation où le système lit et écrit constamment dans le swap
(thrashing) correspond à un manque de mémoire critique pour
l'utilisation. Sans swap, le système ou des processus planteraient. Avec
du swap sur disque dur, le système serait tellement lent qu'il en
deviendrait inutilisable. Avec du swap sur SSD, au moins le système
reste utilisable dans ces conditions. Mais la vraie réponse, c'est
d'augmenter la RAM.

Le swap, c'est fait pour que le système ne crash pas quand il manque de
RAM, il utilise alors le disque.

Pas seulement. Le swap sert aussi à décharger de la mémoire les données
des processus qui sont rarement accédées au profit des caches disque,
dans le but d'améliorer les performances. On peut envisager qu'avec un
SSD très rapide (type NVMe), l'écart réduit entre la vitesses de la RAM
et la vitesse du stockage rend le besoin d'un gros cache disque moins fort.

On 1/27/19 9:30 AM, Pascal Hambourg wrote:

Le 27/01/2019 à 07:52, Basile Starynkevitch a écrit :

Je crois savoir qu'il est important de monter le SSD avec l'option
discard qui n'est pas active par défaut.

Apparemment l'option discard n'est pas le moyen recommandé pour
effectuer le TRIM. Il serait préférable de lancer un "batch TRIM"
périodique avec la commande fstrim du paquet util-linux. Le paquet
util-linux inclut dans ses exemples un service systemd qu'on peut
utiliser à cet effet.

Un grand merci pour le conseil.

Les arguments avancés sont qu'avec certains SSD, l'option discard est
susceptible de pénaliser les performances (en bloquant les autres
opérations de lecture/écriture ou en déclenchant un garbage collector
immédiat) et/ou d'accélérer l'usure du SSD (en déclenchant le garbage
collector trop souvent).

Je connais bien les GCs au sens logiciel du mot (voir
http://gchandbook.org/ pour plus de détails), et j'en ai implémenté
quelques uns (dans Qish, dans GCC MELT, dans bismon) - tous en logiciels
libres (et il y a plus de 10 ans dans le projet TWO qui est FP5 ou FP6
européen mais propriétaire). Je trouve la terminologie "garbage
collector" dans les SSD  trop ambitieuse. Cf
https://en.wikipedia.org/wiki/Write_amplification#BG-GC

Et ma partition de swap n'est pas sur SSD.

Je précise plusieurs choses:

J'ai des desktops aussi bien au boulot qu'à la maison. Sous Debian/Sid
dans les deux cas. Avec un SSD et un disque rotatif et deux grands
écrans dans les deux cas.

Je travaille principalement sur bismon (à temps à peu près plein). C'est
un logiciel libre (GPLv3+), pas encore publié (not yet released) mais
dont le code source encore embryonnaire est déjà disponible en
http://github.com/bstarynk/bismon/ et il évolue constamment. Ce bismon
est un système persistent et homoiconique. Pour plus de détails, lire
mon brouillon de rapport (en anglais, futur livrable ou fourniture d'un
projet européen H2020)
http://starynkevitch.net/Basile/bismon-chariot-doc.pdf qui évolue encore
souvent. Ceux qui ont le courage de lire et commenter ma prose sont
bienvenus (le rapport final est dû en 2020, mais ça m'arrangerait qu'il
soit acceptable). Bismon est financé par les projets européens H2020
CHARIOT et DECODER mentionnés dans son README.md

J'ai des machines assez grosses: au boulot, une station Dell 7920 avec
128Gigaoctets de RAM et un Intel Xeon Silver 4114T à 10 coeurs. A la
maison, je viens de commander une machine avec 64Gigaoctets de RAM
(extensible à 128) et un Threadripper 2970WX (et j'attends sa livraison
avec impatience) à 24 coeurs. En ce moment précis, j'utilise encore un
vieux i5-4690S avec 32Go de RAM à la maison. Dans deux semaines tout au
plus, ça va changer.

Je ne fait pas d'hibernation (au sens système du mot), car bismon est
persistent et donc "hiberne" par lui même. Pour plus de détails, lire
mon rapport et/ou mon README.

La plupart du temps, le swap n'est pas utilisé. La commande free indique
une utilisation nulle de swap. Comme j'ai du disque et du SSD, et comme
le SSD est plus rapide que le disque, je prefère le consacrer à autre
chose. Du coup, je mais la partition de swap sur le SSD.

Quand j'aurais effectivement un processus bismon qui dépasse les 100Go
(peut-être dans un an) je songerais éventuellement à swapper sur un
fichier du SSD. Pour l'instant, le swap ne sert quasiment jamais, et je
ne veux pas gaspiller du SSD pour un gros truc inutile comme une grosse
zone de swap, alors que j'ai besoin d'accéder à des fichiers -parfois un
peu volumineux- qui méritent d'être sur le SSD.

Je tiens toutefois à une zone de swap comparable à la taille de ma RAM,
pour éventuellement pouvoir hiberner mon système (ce que je fais en
pratique très rarement: à la maison, mon ordinateur reste allumé 24h/24,
au boulot je l'allume le matin avant le café; les consignes de sécurité
incendie déconseillent de laisser un desktop allumé la nuit).

Cordialement, et merci des conseils

--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France

Le 27/01/2019 à 12:45, Basile Starynkevitch a écrit :

Je trouve la terminologie "garbage
collector" dans les SSD  trop ambitieuse.

Pourquoi, et quelle appellation te semblerait plus appropriée ?

La plupart du temps, le swap n'est pas utilisé. La commande free indique
une utilisation nulle de swap. Comme j'ai du disque et du SSD, et comme
le SSD est plus rapide que le disque, je prefère le consacrer à autre
chose.

D'accord. C'est le type d'argument valable et réfléchi auquel je
m'attendais.

Du coup, je mets la partition de swap sur le SSD.

Sur le disque dur, tu veux dire.

Quand j'aurais effectivement un processus bismon qui dépasse les 100Go
(peut-être dans un an) je songerais éventuellement à swapper sur un
fichier du SSD. Pour l'instant, le swap ne sert quasiment jamais, et je
ne veux pas gaspiller du SSD pour un gros truc inutile comme une grosse
zone de swap, alors que j'ai besoin d'accéder à des fichiers -parfois un
peu volumineux- qui méritent d'être sur le SSD.

Je tiens toutefois à une zone de swap comparable à la taille de ma RAM,
pour éventuellement pouvoir hiberner mon système (ce que je fais en
pratique très rarement

Note qu'on peut mettre un "petit" swap rapide de haute priorité sur le
SSD pour ne pas effondrer les performances en cas de pic transitoire de
consommation mémoire et un gros swap lent de plus basse priorité sur le
disque dur pour l'hibernation occasionnelle.

On 1/27/19 3:09 PM, Pascal Hambourg wrote:

Le 27/01/2019 à 12:45, Basile Starynkevitch a écrit :

Je trouve la terminologie "garbage collector" dans les SSD  trop
ambitieuse.

Pourquoi, et quelle appellation te semblerait plus appropriée ?

Personnellement, j'appellerais ça plutôt : compaction, ou
reorganisation, ou reordonnancement. Un GC est un parcours de graphe, et
les secteurs d'un SSD ne sont pas organisés en graphe profond (tout au
plus en arbre ou en peigne).

La plupart du temps, le swap n'est pas utilisé. La commande free
indique une utilisation nulle de swap. Comme j'ai du disque et du
SSD, et comme le SSD est plus rapide que le disque, je prefère le
consacrer à autre chose.

D'accord. C'est le type d'argument valable et réfléchi auquel je
m'attendais.

Du coup, je mets la partition de swap sur le SSD.

Sur le disque dur, tu veux dire.

Oui, ma langue a fourché.

Quand j'aurais effectivement un processus bismon qui dépasse les
100Go (peut-être dans un an) je songerais éventuellement à swapper
sur un fichier du SSD. Pour l'instant, le swap ne sert quasiment
jamais, et je ne veux pas gaspiller du SSD pour un gros truc inutile
comme une grosse zone de swap, alors que j'ai besoin d'accéder à des
fichiers -parfois un peu volumineux- qui méritent d'être sur le SSD.

Je tiens toutefois à une zone de swap comparable à la taille de ma
RAM, pour éventuellement pouvoir hiberner mon système (ce que je fais
en pratique très rarement

Note qu'on peut mettre un "petit" swap rapide de haute priorité sur le
SSD pour ne pas effondrer les performances en cas de pic transitoire
de consommation mémoire et un gros swap lent de plus basse priorité
sur le disque dur pour l'hibernation occasionnelle.

A mon avis (mais le tien m'interesse et tu es plus compétent), en
pratique, pour ce genre de cas, swapper sur un fichier pourrait suffire.
Et je mettrais alors ce fichier en priorité haute pour le swap. Pas
besoin, me semble-t-il, de reserver une partition de swap sur le SSD.

A priori j'ai largement assez de RAM.


Cordialement.

--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France

Le 27/01/2019 à 16:17, Basile Starynkevitch a écrit :

On 1/27/19 3:09 PM, Pascal Hambourg wrote:

Le 27/01/2019 à 12:45, Basile Starynkevitch a écrit :

Je trouve la terminologie "garbage collector" dans les SSD  trop
ambitieuse.

Pourquoi, et quelle appellation te semblerait plus appropriée ?

Personnellement, j'appellerais ça plutôt : compaction, ou
reorganisation, ou reordonnancement. Un GC est un parcours de graphe, et
les secteurs d'un SSD ne sont pas organisés en graphe profond (tout au
plus en arbre ou en peigne).

Tu me parles chinois...

Note qu'on peut mettre un "petit" swap rapide de haute priorité sur le
SSD pour ne pas effondrer les performances en cas de pic transitoire
de consommation mémoire et un gros swap lent de plus basse priorité
sur le disque dur pour l'hibernation occasionnelle.

A mon avis (mais le tien m'interesse et tu es plus compétent), en

Pas vraiment, non. Ce qui précède le démontre

pratique, pour ce genre de cas, swapper sur un fichier pourrait suffire.

Si tu veux vraiment mon avis sur l'utilisation d'un fichier comme swap,
il est bien tranché : c'est un sale hack à éviter car ça repose sur la
condition que le noyau puisse établir un mapping statique entre le
fichier de swap et les blocs du périphérique sous-jacent afin d'accéder
directement à ceux-ci en court-circuitant la couche du système de
fichiers. Or certains types de systèmes de fichiers (btrfs, nilfs2, et
je n'ose même pas penser aux systèmes de fichiers non basés sur un
périphérique bloc comme ubifs) ou de fichiers (creux, préalloués sur
ext4 ou xfs) ne permettent pas cela. Cf. les pages de manuel de mkswap
et swapon.

La seule façon propre d'utiliser un fichier comme swap, c'est de
l'associer à un périphérique loop et d'utiliser ce dernier comme swap,
pour forcer le noyau à passer par le système de fichiers. Evidemment, ça
dégrade un peu les performances.

Le 27/01/2019 à 09:52, Pascal Hambourg a écrit :

La situation où le système lit et écrit constamment dans le swap
(thrashing) correspond à un manque de mémoire critique pour
l'utilisation. Sans swap, le système ou des processus planteraient. Avec
du swap sur disque dur, le système serait tellement lent qu'il en
deviendrait inutilisable. Avec du swap sur SSD, au moins le système
reste utilisable dans ces conditions. Mais la vraie réponse, c'est
d'augmenter la RAM.

Pas forcement totalement inutilisable. Sur mes ordinosaures je peux
avoir jusqu'a environ cinq fois plus d'espace pour l'echange que de RAM,
mais avec quelques scripts et en surveillant ce qui se passe avec top,
je m'en sors, faut juste parfois laisser les fuites memoires
mozilleennes se faire avant de retrouver la main :-/

PS: pour la personne qui constate des debits reels un peu plus faibles
de son SSD par rapport a ceux annonces, ca peut etre lie a l'interface
de connexion entre celui-ci et la CM.

--
Cordialement, Stephane Ascoet

Le 28/01/2019 à 00:28, Gaëtan Perrier a écrit :

Au début d'Unix les SSD n'existaient pas ...

Les SSD à base de mémoire flash que nous connaissons maintenant, non.
Mais en ce temps là il existait des SSD au sens littéral "disque solide"
basés sur d'autres technologies comme la DRAM ou les CCD (oui, comme les
capteurs des appareils photo numériques et les caméras) associées avec
une batterie pour la persistance.

Cf.
<https://en.wikipedia.org/wiki/Solid-state_drive#Development_and_history>

Le 28/01/2019 à 10:34, Stephane Ascoet a écrit :

Le 27/01/2019 à 09:52, Pascal Hambourg a écrit :

La situation où le système lit et écrit constamment dans le swap
(thrashing) correspond à un manque de mémoire critique pour
l'utilisation. Sans swap, le système ou des processus planteraient. Avec
du swap sur disque dur, le système serait tellement lent qu'il en
deviendrait inutilisable. Avec du swap sur SSD, au moins le système
reste utilisable dans ces conditions. Mais la vraie réponse, c'est
d'augmenter la RAM.

Pas forcement totalement inutilisable. Sur mes ordinosaures je peux
avoir jusqu'a environ cinq fois plus d'espace pour l'echange que de RAM,

Ce qui caractérise le "thrashing" n'est pas le volume d'occupation du
swap mais son activité élevée, c'est-à-dire quand le système passe son
temps à lire et écrire dans le swap sans pouvoir faire grand-chose d'autre.

<https://fr.wikipedia.org/wiki/Thrashing>

On 1/28/19 9:14 PM, Pascal Hambourg wrote:

Le 28/01/2019 à 00:28, Gaëtan Perrier a écrit :

Au début d'Unix les SSD n'existaient pas ...

Les SSD à base de mémoire flash que nous connaissons maintenant, non.
Mais en ce temps là il existait des SSD au sens littéral "disque
solide" basés sur d'autres technologies comme la DRAM ou les CCD (oui,
comme les capteurs des appareils photo numériques et les caméras)
associées avec une batterie pour la persistance.

C'était extrêmement cher. Je travaille au CEA, et à l'époque (1987)
j'étais richement équipé (une station sun 3/160, coûtant 3 ou 4 ans de
mon salaire) et j'avais juste un disque rotatif (si j'ai bonne mémoire,
de 100Go? ou peut-être 300Go?, ou peut-être que c'était des megaoctets;
la RAM faisait 8Mo upgradé à 12Mo).


A l'époque, j'entendais parler de disque solide, mais c'était juste un rêve.


Et j'insiste, j'avais en ce temps là un équipement exceptionnel, si on
le jauge avec mon salaire.

Cordialement

--

Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France