cerhu > linux.debian.user.french

Cyrille Biot (25/01/2019, 23h40)
>> D'ailleurs si il y avait une fonction pour que thunderbird oublie les
>> mots de passe des boites mails avant d'hiberner / mettre en veille, ca
>> serait cool.

Avec pm-utils, il doit y avoir moyen de gérer cela, non ?
Il suffit de vider "vider" le fichier où ils sont stockés et de
configurer ensuite les crochets de pm-utils
Patrice Constans (26/01/2019, 20h50)
*Bonsoir,**
**Ce qui serait encore plus cool serait que personne ne puisse, à
l'ouverture de thunderbird, lire ou prendre connaissance d'un mail tant
qu'il n'a pas saisi le bon mot de passe.**
**Bonne soirée à tous, Patrice.*

Le 25/01/2019 à 15:29, Cyrille Biot a écrit :
[..]
Basile Starynkevitch (27/01/2019, 09h00)
On 1/24/19 9:04 PM, Daniel Caillibaud wrote:
> Le 24/01/19 à 17:22, contact <contact> a écrit :
> Idem, et j'écris comme un goret sur le disque (dev nodeJs, donc tout de
> temps en train d'installer / virer des modules avec leurs milliers de
> fichiers, dump de bases à gogo pas tendre avec le disque, etc.), mais mon
> disque actuel est pas si vieux
> Bref, pour un usage de PC domestique un ssd devrait tenir des années, même
> en usage intensif (ou pas, car ça reste faillible => sauvegardes
> régulières).


D'accord avec vous deux. Je crois savoir qu'il est important de monter
le SSD avec l'option discard qui n'est pas active par défaut. Par
exemple mon /etc/fstab contient

# / was on /dev/sda1 during installation
UUID=371a29d9-f803-4f12-a113-f3592a60a9ea /               ext4
errors=remount-ro,discard 0       1

et /dev/sda est un SSD, et j'ai du rajouter le discard à la main.

Cette option fait que le pilote prévient le SSD, par la technologie TRIM
(cf [..]) ...) des secteurs
libérés.

Par contre, j'ai entendu dire que, contrairement aux disques rotatifs
mécaniques, un SSD tombe totalement en panne tout d'un coup. Alors qu'un
disque mécanique donne souvent des signes de faiblesses avant la panne
totale. Conséquemment, je sauvegarde automatiquement par un crontab
toutes les données importantes vers un disque rotatatif.

Et ma partition de swap n'est pas sur SSD.
Pascal Hambourg (27/01/2019, 10h40)
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.

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

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


Pourquoi ?
Pascal Hambourg (27/01/2019, 11h00)
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 ?
Pascal Hambourg (27/01/2019, 11h00)
Le 25/01/2019 à 08:38, Daniel Caillibaud a écrit :
> Le 25/01/19 à 07:35, aishen <aishen> a écrit :
> ????
> Quel rapport entre le besoin de swap (manque de RAM du système) et la
> nature du disque ?


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.
Pascal Hambourg (27/01/2019, 11h20)
Le 25/01/2019 à 11:27, Sébastien Dinot a écrit :
> J'ai une partition de swap sur mon disque NVMe, mais vu le niveau de performance de ce disque (surtout en lecture en ce qui me concerne, vu qu'en écriture, le débit est sérieusement ralenti par la capacité de chiffrement du processeur),


Le chiffrement n'est pas symétrique ?
Sébastien Dinot (27/01/2019, 13h30)
Bonjour,

Pascal Hambourg a écrit :
> Le chiffrement n'est pas symétrique ?


Le chiffrement symétrique est réputé bien plus performant que le
chiffrement assymétrique, mais symétrique ne veut nullement dire que
chiffrement et déchiffrement ont le même cout. Dans la pratique, le
chiffrement se révèle bien plus couteux que le déchiffrement.

Un benchmark que j'ai trouvé sur le net crédite le disque NVME qui
équipe mon portable des performances suivantes :

Écriture : 780 Mo/s
Lecture : 1190 Mo/s

Pour ma part, j'avais effectué des tests avant de le chiffrer et j'avais
constaté les performances suivantes :

Écriture : 800 Mo/s
Lecture : 960 Mo/s

Je viens à l'instant d'effectuer un test rapide sur mon disque chiffré
et j'ai obtenu les résultats suivants :

Écriture : 92 Mo/s
Lecture : 805 Mo/s

Du coup, lorsque j'effectue des compilations intensives d'un gros projet
en C++ comme c'est le cas actuellement, le chiffrement est pénalisant
(le volume du projet - 13 Go de données produites - faisant que tous les
fichiers générés ne peuvent être cachés en mémoire). Mais vu que la
compilation ex-nihilo dudit projet prend 58 minutes, ce ne sont pas les
2 minutes d'écriture des données sur disque qui ralentissent mon
travail...

Et le reste du temps, il serait hypocrite de ma part de dire que je
perçois l'impact du chiffrement du disque.

Sébastien
Basile Starynkevitch (27/01/2019, 14h10)
On 1/27/19 9:30 AM, Pascal Hambourg wrote:
> Le 27/01/2019 à 07:52, Basile Starynkevitch a écrit :
> 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
[..] 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
[..]
>> 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
[..] 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)
[..] 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
Pascal Hambourg (27/01/2019, 16h10)
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.
Basile Starynkevitch (27/01/2019, 17h20)
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).

> D'accord. C'est le type d'argument valable et réfléchi auquel je
> m'attendais.
> Sur le disque dur, tu veux dire.


Oui, ma langue a fourché.

>> 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.
Pascal Hambourg (27/01/2019, 19h20)
Le 27/01/2019 à 16:17, Basile Starynkevitch a écrit :
> On 1/27/19 3:09 PM, Pascal Hambourg wrote:
> 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.
Pascal Hambourg (27/01/2019, 20h00)
Le 27/01/2019 à 12:24, Sébastien Dinot a écrit :
> Le chiffrement symétrique est réputé bien plus performant que le
> chiffrement assymétrique, mais symétrique ne veut nullement dire que
> chiffrement et déchiffrement ont le même cout. Dans la pratique, le
> chiffrement se révèle bien plus couteux que le déchiffrement.


Pour quelle(s) raison(s) ? Le découpage en blocs qui implique une
lecture-modification-écriture en cas de modification partielle d'un bloc
(comme les bandes en RAID 5) ?

> Pour ma part, j'avais effectué des tests avant de le chiffrer et j'avais
> constaté les performances suivantes :
> Écriture : 800 Mo/s
> Lecture : 960 Mo/s
> Je viens à l'instant d'effectuer un test rapide sur mon disque chiffré
> et j'ai obtenu les résultats suivants :
> Écriture : 92 Mo/s
> Lecture : 805 Mo/s


Effectivement ça fait très mal...
Une telle chute en écriture me surprend quand même beaucoup. Comment
as-tu testé pour obtenir ces valeurs ?
Je n'ai pas ce genre de matériel mais j'ai fait un test sur ma petite
machine avec un volume chiffré LUKS et j'obtiens une chute de 15% en
lecture et 30% en écriture séquentielle brute avec dd.
Gaëtan Perrier (28/01/2019, 01h30)
Au début d'Unix les SSD n'existaient pas ...
Le swap reste utile ne serait-ce que pour l'hibernation d'une machine, il me
semble.

Le vendredi 25 janvier 2019 à 08:56 +0100, aishen a écrit :
[..]
Sébastien Dinot (28/01/2019, 01h40)
Pascal Hambourg a écrit :
> Pour quelle(s) raison(s) ? Le découpage en blocs qui implique une
> lecture-modification-écriture en cas de modification partielle d'un
> bloc (comme les bandes en RAID 5) ?


Je ne suis pas un spécialiste de ces questions, mais je sais que la
limite vient de la capacité de chiffrement du processeur (les dernières
générations ayant fait d'énormes progrès) et l'expérience montre que le
chiffrement d'un flux est bien plus lent que son déchiffrement.

> Une telle chute en écriture me surprend quand même beaucoup. Comment
> as-tu testé pour obtenir ces valeurs ?


Pour la lecture, je copie un gros fichier dans le répertoire /tmp,
sachant qu'il s'agit d'une partition tmpfs (donc montée en mémoire) :

sync ; time ( cp debian-9.7.0-amd64-DVD-1.iso /tmp ; sync )

NB ; Ce test n'est consistant que lors du premier essai car les fois
suivantes, le fichier est en cache et les performances apparentes
dépassent les performances théoriques du disque.

Pour l'écriture, je duplique ce fichier sur disque :

sync ; time ( cp /tmp/debian-9.7.0-amd64-DVD-1.iso ~/ ; sync )

Au passage, j'ai effectué deux autres tests ce soir, avec d'autres
fichiers de plusieurs Go, et je constate une certaine variabilité :

Écriture : entre 82 et 109 Mo/s
Lecture : entre 724 et 830 Mo/s

> Je n'ai pas ce genre de matériel mais j'ai fait un test sur ma petite
> machine avec un volume chiffré LUKS et j'obtiens une chute de 15% en
> lecture et 30% en écriture séquentielle brute avec dd.


La vitesse d'écriture d'un disque dur SATA mécanique plafonnant aux
alentours des 120 Mo/s environ, la capacité de chiffrement du processeur
n'est pas le facteur limitatif car le processeur chiffre les données
plus vite que le disque ne peut les enregistrer (enfin, si l'on
considère un processeur multi-c?ur pas trop poussif et ancien).

Lorsque j'utilisais un disque mécanique, la compilation été ralentie
parce qu'un c?ur était largement occupé par le chiffrement, mais les
écritures sur disque n'était pas ralenties par le processeur.

Sébastien

Discussions similaires
[DISQUE) lion et création d'une partition Snow-Léopard sur le même disque

sauver sur disque la page 4 uniquement dans le classeur existantsur disque

Insérer pièce jointe : Disque C.lnk (impossibilité de parcourir l'arborescence de mon disque)

[Win2000] transférer disque system C vers nouveau disque D et renommer D en C


Fuseau horaire GMT +2. Il est actuellement 20h35. | Privacy Policy