Re: Disque Dur SSD

[Sébastien Dinot]

Bonjour,

- Mail original -
> Ne pas oublier que pas mal de SSD récents ont une zone tampon
> beaucoup plus rapide que le reste du SSD. Tant que les transferts
> ont une taille plus petite que cette zone tout va bien ça boost
> par contre quand ça déborde les perf diminuent fortement...

Je ne sais pas quelle est la taille de ce cache en général. En ce qui me 
concerne, le test a été effectué avec un disque NVMe de type PC401 NVMe SK 
hynix 512GB, mais je n'ai pas trouvé l'information sur la fiche de 
spécifications :

https://www.skhynix.com/eng/product/ssdClient.jsp

Et j'ai utilisé un fichier de 3,4 Go.

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: Disque Dur SSD

[Pascal Hambourg]

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

Le mercredi 30 janvier 2019 à 21:53 +0100, Sébastien Dinot a écrit :

Pascal Hambourg a écrit :


J'ai fait des tests similaires sur un PC "récent" (pour moi : 6 ans),
sans SSD mais avec 16 Gio de RAM donc à la place du SSD j'ai utilisé
un ramdisk que j'ai chiffré avec LUKS, options par défaut. J'obtiens
un débit d'environ 1 Go/s aussi bien en lecture qu'en écriture, en
accès direct au volume chiffré ou à travers un système de fichiers
ext4.


J'en suis surpris car cela voudrait dire que la forte dégradation des
performances en écriture est essentiellement due à un volume de données
à écrire bien plus important (ce que peut expliquer un chiffrement par
bloc). (...)


Ne pas oublier que pas mal de SSD récents ont une zone tampon beaucoup plus
rapide que le reste du SSD. Tant que les transferts ont une taille plus petite
que cette zone tout va bien ça boost par contre quand ça déborde les perf
diminuent fortement...


Dans ce cas la même dégradation devrait être observable avec et sans 
chiffrement.

Re: Disque Dur SSD

[Gaëtan Perrier]

Le mercredi 30 janvier 2019 à 21:53 +0100, Sébastien Dinot a écrit :
> Bonsoir,
> 
> Pascal Hambourg a écrit :
> > Note : le contenu d'un tmpfs n'est pas forcément en permanence en
> > mémoire, il peut aussi aller dans le swap.
> 
> En effet, cette information se vérifie dans la doc du noyau Linux :
> 
> https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt
> 
> Je ne le savais pas et cela explique probablement la variabilité des
> résultats que j'obtenais et que je ne m'expliquais pas (le test étant
> effectué sur une machine non chargée).
> 
> > Note : pas besoin de copier dans un vrai fichier pour le test en
> > lecture, on peut copier vers /dev/null.
> 
> Exact. C'est encore mieux.
> 
> > J'ai fait des tests similaires sur un PC "récent" (pour moi : 6 ans),
> > sans SSD mais avec 16 Gio de RAM donc à la place du SSD j'ai utilisé
> > un ramdisk que j'ai chiffré avec LUKS, options par défaut. J'obtiens
> > un débit d'environ 1 Go/s aussi bien en lecture qu'en écriture, en
> > accès direct au volume chiffré ou à travers un système de fichiers
> > ext4.
> 
> J'en suis surpris car cela voudrait dire que la forte dégradation des
> performances en écriture est essentiellement due à un volume de données
> à écrire bien plus important (ce que peut expliquer un chiffrement par
> bloc). Je n'en ai pas le temps sur l'instant, mais je ferai le même test
> chez moi ce week-end pour voir ce qu'il donne.
> 

Ne pas oublier que pas mal de SSD récents ont une zone tampon beaucoup plus
rapide que le reste du SSD. Tant que les transferts ont une taille plus petite
que cette zone tout va bien ça boost par contre quand ça déborde les perf
diminuent fortement...

Gaëtan


signature.asc
Description: This is a digitally signed message part

Re: Disque Dur SSD

[Sébastien Dinot]

Bonsoir,

Pascal Hambourg a écrit :
> Note : le contenu d'un tmpfs n'est pas forcément en permanence en
> mémoire, il peut aussi aller dans le swap.

En effet, cette information se vérifie dans la doc du noyau Linux :

https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt

Je ne le savais pas et cela explique probablement la variabilité des
résultats que j'obtenais et que je ne m'expliquais pas (le test étant
effectué sur une machine non chargée).

> Note : pas besoin de copier dans un vrai fichier pour le test en
> lecture, on peut copier vers /dev/null.

Exact. C'est encore mieux.

> J'ai fait des tests similaires sur un PC "récent" (pour moi : 6 ans),
> sans SSD mais avec 16 Gio de RAM donc à la place du SSD j'ai utilisé
> un ramdisk que j'ai chiffré avec LUKS, options par défaut. J'obtiens
> un débit d'environ 1 Go/s aussi bien en lecture qu'en écriture, en
> accès direct au volume chiffré ou à travers un système de fichiers
> ext4.

J'en suis surpris car cela voudrait dire que la forte dégradation des
performances en écriture est essentiellement due à un volume de données
à écrire bien plus important (ce que peut expliquer un chiffrement par
bloc). Je n'en ai pas le temps sur l'instant, mais je ferai le même test
chez moi ce week-end pour voir ce qu'il donne.

Et en conclusion, je te le confirme, tu es bien plus intéressant à lire
quand tu fournis une réponse argumentée que lorsque tu réponds
« Absurde ».

Bonne soirée,

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: Disque Dur SSD

[Pascal Hambourg]

Le 28/01/2019 à 00:31, Sébastien Dinot a écrit :


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.

(...)

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


Note : le contenu d'un tmpfs n'est pas forcément en permanence en 
mémoire, il peut aussi aller dans le swap.



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


Note : pas besoin de copier dans un vrai fichier pour le test en 
lecture, on peut copier vers /dev/null.



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

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


J'ai fait des tests similaires sur un PC "récent" (pour moi : 6 ans), 
sans SSD mais avec 16 Gio de RAM donc à la place du SSD j'ai utilisé un 
ramdisk que j'ai chiffré avec LUKS, options par défaut. J'obtiens un 
débit d'environ 1 Go/s aussi bien en lecture qu'en écriture, en accès 
direct au volume chiffré ou à travers un système de fichiers ext4.

Re: Disque Dur SSD

[Basile Starynkevitch]

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

Re: Disque Dur SSD

[Pascal Hambourg]

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


Quel est l'intérêt de faire de la compilation sur une partition chiffrée ?


Comme n'importe quel traitement, le résultat d'une compilation peut 
contenir des données sensibles qu'on souhaite protéger.



Normalement une très grande partie des données de compilation se trouvent
effacées à la fin de celle-ci.


Supprimer un fichier ne signifie pas effacer son contenu.

Re: Disque Dur SSD

[Pascal Hambourg]

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.

Re: Disque Dur SSD

[Pascal Hambourg]

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. 

Re: Disque Dur SSD

[Sébastien Dinot]

Bonjour,

- Mail original -
> Quel est l'intérêt de faire de la compilation sur une partition
> chiffrée ?

L'intégralité de mon disque est chiffré (hormis la partition /boot). Ce 
faisant, en cas de vol (la principale menace), le PC est perdu, mais aucune 
information personnelle ou professionnelle ne se retrouve dans la nature. Ce 
choix n'a donc rien de spécifique à la compilation.

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: Disque Dur SSD

[Stephane Ascoet]

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

Re: Disque Dur SSD

[Gaëtan Perrier]

Le dimanche 27 janvier 2019 à 12:24 +0100, Sébastien Dinot a écrit :
> 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...

Quel est l'intérêt de faire de la compilation sur une partition chiffrée ?
Normalement une très grande partie des données de compilation se trouvent
effacées à la fin de celle-ci. Donc les chiffrer me semble peu pertinent, non ?

Gaëtan


signature.asc
Description: This is a digitally signed message part

Re: Disque Dur SSD

[Sébastien Dinot]

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

-- 
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: Disque Dur SSD

[Gaëtan Perrier]

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 :
> 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, il n'y 
> a pas d'intérêt de ce côté, mais les ssd on un cycle (grand) de 
> copy/effacer dont il ne vaut pas mieux aller au delà. De toute façon 
> importe chacun fait ce qu'il veut mais ne devrait pas être traité 
> d'absurde ou idiot... Comme disent les enfants, idiot lui-même celui qui 
> le prononce !
> Le 25/01/2019 à 08:38, Daniel Caillibaud a écrit :
> > Le 25/01/19 à 07:35, aishen  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
> > Quels avis ? Je suis assez curieux de voir qui peut bien raconter ça…
> > 
> > Le swap, c'est fait pour que le système ne crash pas quand il manque de
> > RAM, il utilise alors le disque.
> > 
> > Et dans ce cas, c'est quand même beaucoup mieux d'avoir un disque rapide…
> > (Cf discussion "Partitionnement d'un serveur web" initiée le 14/01)
> > 
> > Je suis donc de l'avis de Pascal Hambourg, ça me parait idiot de pas mettre
> > de swap parce qu'on a un disque ssd.
> > 
> > Ça peut se justifier de ne pas mettre de swap, mais ça n'a rien à voir avec
> > ssd ou pas.
> > 



signature.asc
Description: This is a digitally signed message part

Re: Disque Dur SSD

[Pascal Hambourg]

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.

Re: Disque Dur SSD

[Pascal Hambourg]

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.

Re: Disque Dur SSD

[Basile Starynkevitch]

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

Re: Disque Dur SSD

[Pascal Hambourg]

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.

Re: Disque Dur SSD

[Basile Starynkevitch]

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

Re: Disque Dur SSD

[Sébastien Dinot]

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

-- 
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: Disque Dur SSD

[Pascal Hambourg]

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 ?

Re: Disque Dur SSD

[Pascal Hambourg]

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 ?

Re: Disque Dur SSD

[Pascal Hambourg]

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

Le 25/01/19 à 07:35, aishen  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.

Re: Disque Dur SSD

[Pascal Hambourg]

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 ?

Re: Disque Dur SSD

[Basile Starynkevitch]

On 1/24/19 9:04 PM, Daniel Caillibaud wrote:

Le 24/01/19 à 17:22, contact  a écrit :

Bonjour

retour d'expérience, j'ai un SSD avec tout dessus, sous Debian depuis 4
ans et je m'en sert quotidiennement sans aucun problèmes à ce jour.

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 https://en.wikipedia.org/wiki/Trim_(computing) ...) 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.


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

Re: Disque Dur SSD

[Patrice Constans]

*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 :

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




--
"Mai los ases son vièlhs, mai venon fats  !"

const...@univ-perp.fr

Patrice CONSTANS
Installations Informatiques
I.U.T. de Perpignan,
Dept. Statistique et Informatique Décisionnelle
11000 CARCASSONNE
Tel : 04 68 47 74 57
Fax : 04 68 47 71 63

ATTENTION Le message contenu dans cet email ainsi que dans tout fichier attaché 
est destiné exclusivement aux personnes dont le nom figure ci-dessus. Il peut 
contenir des informations confidentielles ou protégées par le secret 
professionnel et dont la divulgation est strictement prohibée. Si vous avez 
reçu cet email par erreur,détruisez-en le contenu. Vous n'êtes pas autorisé, 
dans cette hypothèse, à copier, distribuer ou conserver ce message. Merci.

WARNING This information in this mail and in any attachments is intended for 
the above-mentioned addressees only. It may contain privileged or confidential 
informationthe review, dissemination or disclosure of which is strictly 
prohibited. If you have received this email by error, please destroy it. In 
this case, you are not authorisedto disclose, copy, distribute, or retain this 
message or any part of it. Thank you.

Re: Disque Dur SSD

[Cyrille Biot]

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

Re: Disque Dur SSD

[Yann Serre]

Bonsoir,
L’hibernation c'est bien pratique sur un portable.
On attend quelqu'un et quand cette personne arrive on ferme juste 
l'écran et on glisse le portable dans son sac.

Sinon, pas très utile quand on a le temps de fermer sa session ?

Re: Disque Dur SSD

[hamster]

Le 25/01/2019 à 15:08, Pierre L. a écrit :
> ALT-F4 sur Thunderbird avant la mise en hibernation ?

Ca ferme thunderbird ca. Si on a un mail en cours de rédaction, ca perme
pas de retrouver la fenetre de rédaction ouverte quand on le réveille.

Re: Disque Dur SSD

[Pierre L.]

ALT-F4 sur Thunderbird avant la mise en hibernation ?


Le 25/01/2019 à 11:35, hamster a écrit :
> 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.




signature.asc
Description: OpenPGP digital signature

Re: Disque Dur SSD

[Sébastien Dinot]

- Mail original -
> J'ai l'impression a ce que tu dis que pour toi l'interet de
> l'hibernation se situe au niveau de la rapidité du reveil. Mais pour
> moi c'est surtout le fait de retrouver mon travail en cours, de pas
> avoir a tout fermer quand j'éteins puis tout rouvrir ensuite.

En effet, je ne nie pas l'intérêt de retrouver sa session de travail en l'état, 
mais en ce qui me concerne, le contexte réseau et mes activités changent à 
chaque fois que je me déplace. Du coup, la persistance de la session de travail 
n'a pas beaucoup d'intérêt. :)

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: Disque Dur SSD

[Sébastien Dinot]

- Mail original -
> J'ai l'impression a ce que tu dis que pour toi l'interet de
> l'hibernation se situe au niveau de la rapidité du reveil. Mais pour
> moi c'est surtout le fait de retrouver mon travail en cours, de pas
> avoir a tout fermer quand j'éteins puis tout rouvrir ensuite.

En effet, je ne nie pas l'intérêt de retrouver sa session de travail en l'état, 
mais en ce qui me concerne, le contexte réseau et mes activités changent peu ou 
prou à chaque fois que je me déplace. :)

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: Disque Dur SSD

[aishen]

je ne sais pas... J'utilise pas "hiberne"

Mais un ssd c'est très rapide... Plus besoin d'hiberner

Démarrage, environ 5 seconde... c'est vrai j'ai 16 Go de RAM et un AMD 
64 x8, mais enfin aujourd'hui c'est dépassé


Le 25/01/2019 à 11:35, hamster a écrit :

Le 25/01/2019 à 11:27, Sébastien Dinot a écrit :

Bonjour,

- Mail original -

Ah. Comment on fait pour hiberner alors, si on a pas de swap ?

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), l'hibernation perd beaucoup d'intérêt à mes yeux.

J'ai l'impression a ce que tu dis que pour toi l'interet de
l'hibernation se situe au niveau de la rapidité du reveil. Mais pour moi
c'est surtout le fait de retrouver mon travail en cours, de pas avoir a
tout fermer quand j'éteins puis tout rouvrir ensuite.

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.

Re: Disque Dur SSD

[hamster]

Le 25/01/2019 à 11:27, Sébastien Dinot a écrit :
> Bonjour,
>
> - Mail original -
>> Ah. Comment on fait pour hiberner alors, si on a pas de swap ?
> 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), l'hibernation perd beaucoup d'intérêt à mes yeux.

J'ai l'impression a ce que tu dis que pour toi l'interet de
l'hibernation se situe au niveau de la rapidité du reveil. Mais pour moi
c'est surtout le fait de retrouver mon travail en cours, de pas avoir a
tout fermer quand j'éteins puis tout rouvrir ensuite.

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.

Re: Disque Dur SSD

[Sébastien Dinot]

Bonjour,

- Mail original -
> Ah. Comment on fait pour hiberner alors, si on a pas de swap ?

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), l'hibernation perd beaucoup d'intérêt à mes yeux.

Mais le swap reste pertinent pour le reste, même si la quantité de mémoire 
disponible sur les PC récents fait qu'il n'est utilisé par le noyau que par 
anticipation (le noyau cache les pages inutilisées au cas où il aurait besoin 
de mémoire à un moment ou un autre, mais peu ou prou jamais parce qu'il y est 
contraint).

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: Disque Dur SSD

[hamster]

Le 25/01/2019 à 07:35, aishen a écrit :
> on n'a pas besoin de swap sur un ssd linux

Ah. Comment on fait pour hiberner alors, si on a pas de swap ?

Re: Disque Dur SSD

[aishen]

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, il n'y 
a pas d'intérêt de ce côté, mais les ssd on un cycle (grand) de 
copy/effacer dont il ne vaut pas mieux aller au delà. De toute façon 
importe chacun fait ce qu'il veut mais ne devrait pas être traité 
d'absurde ou idiot... Comme disent les enfants, idiot lui-même celui qui 
le prononce !

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

Le 25/01/19 à 07:35, aishen  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

Quels avis ? Je suis assez curieux de voir qui peut bien raconter ça…

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

Et dans ce cas, c'est quand même beaucoup mieux d'avoir un disque rapide…
(Cf discussion "Partitionnement d'un serveur web" initiée le 14/01)

Je suis donc de l'avis de Pascal Hambourg, ça me parait idiot de pas mettre
de swap parce qu'on a un disque ssd.

Ça peut se justifier de ne pas mettre de swap, mais ça n'a rien à voir avec
ssd ou pas.

Re: Disque Dur SSD

[aishen]

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

Le 25/01/19 à 07:35, aishen  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

Quels avis ? Je suis assez curieux de voir qui peut bien raconter ça…

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

Et dans ce cas, c'est quand même beaucoup mieux d'avoir un disque rapide…
(Cf discussion "Partitionnement d'un serveur web" initiée le 14/01)

Je suis donc de l'avis de Pascal Hambourg, ça me parait idiot de pas mettre
de swap parce qu'on a un disque ssd.

Ça peut se justifier de ne pas mettre de swap, mais ça n'a rien à voir avec
ssd ou pas.

Re: Disque Dur SSD

[Daniel Caillibaud]

Le 25/01/19 à 07:35, aishen  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

Quels avis ? Je suis assez curieux de voir qui peut bien raconter ça…

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

Et dans ce cas, c'est quand même beaucoup mieux d'avoir un disque rapide…
(Cf discussion "Partitionnement d'un serveur web" initiée le 14/01)

Je suis donc de l'avis de Pascal Hambourg, ça me parait idiot de pas mettre
de swap parce qu'on a un disque ssd.

Ça peut se justifier de ne pas mettre de swap, mais ça n'a rien à voir avec
ssd ou pas.

-- 
Daniel

Si l'herbe est plus verte dans le jardin de ton voisin, laisse-le s'emmerder
à la tondre.
Fred Allen

Re: Disque Dur SSD

[contact]

Bonjour

ceci dépend si j'ai bien compris le fonctionnement du Swap, de la taille 
de la mémoire vie. Plus il y en a et moins tu utilise le Swap, enfin il 
me semble.


donc le désactiver n'est pas forcément nécessaire.

Cordialement

François-Marie BILLARD

Le 24/01/2019 à 23:28, Pascal Hambourg a écrit :

Le 24/01/2019 à 22:50, ajh-valmer a écrit :


Il faut désactiver la SWAP, si disque dur SSD ?


Absurde.

Re: Disque Dur SSD

[aishen]

on n'a pas besoin de swap sur un ssd linux, 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


Le 25/01/2019 à 00:00, Sébastien Dinot a écrit :

Pascal Hambourg a écrit :

Ce n'est pas "un genre de réponse", c'est une réponse. L'objectif est
de répondre que désactiver le swap au prétexte qu'on a un SSD est
absurde. Je suis prêt à lire tes objections.

Ce n'est pas l'avis que je conteste, juste la forme. Un minimum de
cordialité et de forme est toujours souhaitable et une réponse est plus
convaincante quand elle est un tantinet expliquée et argumentée.

Sébastien

Re: Disque Dur SSD

[Sébastien Dinot]

Pascal Hambourg a écrit :
> Ce n'est pas "un genre de réponse", c'est une réponse. L'objectif est
> de répondre que désactiver le swap au prétexte qu'on a un SSD est
> absurde. Je suis prêt à lire tes objections.

Ce n'est pas l'avis que je conteste, juste la forme. Un minimum de
cordialité et de forme est toujours souhaitable et une réponse est plus
convaincante quand elle est un tantinet expliquée et argumentée.

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: Disque Dur SSD

[Patrick Villa]

 
 

Envoyé: jeudi 24 janvier 2019 à 23:28
De: "Pascal Hambourg" 
À: debian-user-french@lists.debian.org
Objet: Re: Disque Dur SSD

Le 24/01/2019 à 22:50, ajh-valmer a écrit :
>
> Il faut désactiver la SWAP, si disque dur SSD ?

 

Le 24/01/2019 "Pascal Hambourg" a écrit :


Absurde.

 

 

Chère liste, mais surtout cher monsieur Hambourg,

 

Vos réponse teintées de condéscendance et d'une bonne dose de mépris sont vraiment désagréables.

 

Au lieu de prendre de haut les personnes qui postent, un minimum de développement serait plus constructif.

 

Je suis nouveau sur cette liste et chaque fois que vous intervenez c'est pareil : une réponse dédaigneuse, mais pas (ou très peu) d'explication en rapport avec la question posée. Ici vous prenez le temps de lire et de répondre à ce monsieur : absurde! C'est bien, mais encore? Votre réponse l'est tout autant.

 

Je ne vais pas rester longtemps sur cette liste je pense, heureusement que tout le monde n'intervient pas de cette manière!
 

 

Pat.

Re: Disque Dur SSD

[Sébastien Dinot]

ajh-valmer a écrit :
> Tant pis, je mets le système et le /home sur le SSD :
> Est-ce dangereux ?

Comme d'autres l'ont rappelé avant moi, tout disque peut lâcher à
n'importe quel moment. Quel que soit le support (i.e. c'est aussi vrai
pour les cartes SD dans les smartphones), il est donc important
d'effectuer des sauvegardes régulières.

Quant aux disques SSD, voire NVMe, leur fiabilité et leur durée de vie
ne cessent de croitre et de nombreux PC portables ne sont équipés de nos
jours que d'un disque SSD ou NVMe.

C'est le cas de mon PC professionnel, mais aussi du portable que fournit
gratuitement la région Occitanie aux lycéens suivant leurs études dans
un établissement ayant le label « lycée numérique ». Or, ce portable
doit durer 3 ans au moins.

Et le disque système de mon PC à la maison est depuis 7 ans déjà un
disque SSD (Zalman F1 de 60 Go). Il n'a toujours pas lâché alors que je
suis en Debian testing et que je mets à jour mon PC quotidiennement (les
écritures sont donc assez nombreuses).

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: Disque Dur SSD

[Pascal Hambourg]

Le 24/01/2019 à 23:38, Sébastien Dinot a écrit :

Pascal Hambourg a écrit :

Absurde.


Quel est l'objectif de ce genre de réponse ?


Ce n'est pas "un genre de réponse", c'est une réponse. L'objectif est de 
répondre que désactiver le swap au prétexte qu'on a un SSD est absurde. 
Je suis prêt à lire tes objections.

Re: Disque Dur SSD

[Sébastien Dinot]

Pascal Hambourg a écrit :
> Absurde.

Quel est l'objectif de ce genre de réponse ? Amener les gens à se
désabonner pour avoir le plaisir de rester entre ours mal léchés ?

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: Disque Dur SSD

[Pascal Hambourg]

Le 24/01/2019 à 22:50, ajh-valmer a écrit :


Il faut désactiver la SWAP, si disque dur SSD ?


Absurde.

Re: Disque Dur SSD

[ajh-valmer]

On Thursday 24 January 2019 21:21:48 aishen wrote:
> j'ai un 249 Go je ne sais quelle marque 30 euros 
> et je formate souvent,  > ubuntu installé depuis 3 ans 
> aucun problème, pas de swap comme indiqué.

Il faut désactiver la SWAP, si disque dur SSD ?

Re: Disque Dur SSD

[aishen]

j'ai un 249 Go je ne sais quelle marque 30 euros et je formate souvent, 
ubuntu installé depuis 3 ans aucun problème, pas de swap comme indiqué


Le 24/01/2019 à 21:04, Daniel Caillibaud a écrit :

Le 24/01/19 à 17:22, contact  a écrit :

Bonjour

retour d'expérience, j'ai un SSD avec tout dessus, sous Debian depuis 4
ans et je m'en sert quotidiennement sans aucun problèmes à ce jour.

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

Power_On_Hours 6853
Total_Host_Sector_Write 11948858760
(ça fait quand même 500 secteurs écrits / s, ça me paraît bcp…)

D'autres ssd sur des serveurs :

Power_On_Hours  22523
Host_Writes_32MiB 1760366
Host_Reads_32MiB  3531769
NAND_Writes_32MiB 2924673

Power_On_Hours  22083
Host_Writes_32MiB  889545
Host_Reads_32MiB  2053073
NAND_Writes_32MiB 1520169

Power_On_Hours   16010
Total_LBAs_Written 1611416
Total_LBAs_Read 918795


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

Re: Disque Dur SSD

[Daniel Caillibaud]

Le 24/01/19 à 17:22, contact  a écrit :
> Bonjour
> 
> retour d'expérience, j'ai un SSD avec tout dessus, sous Debian depuis 4 
> ans et je m'en sert quotidiennement sans aucun problèmes à ce jour.

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

Power_On_Hours 6853
Total_Host_Sector_Write 11948858760
(ça fait quand même 500 secteurs écrits / s, ça me paraît bcp…)

D'autres ssd sur des serveurs :

Power_On_Hours  22523
Host_Writes_32MiB 1760366
Host_Reads_32MiB  3531769
NAND_Writes_32MiB 2924673

Power_On_Hours  22083
Host_Writes_32MiB  889545
Host_Reads_32MiB  2053073
NAND_Writes_32MiB 1520169

Power_On_Hours   16010
Total_LBAs_Written 1611416
Total_LBAs_Read 918795


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

-- 
Daniel

Si le plus grand plaisir des hommes, c'est de se payer le corps des
femmes, je comprends que le plus grand plaisir des femmes soit de se
payer la tete des hommes.
Sacha Guitry

Re: Disque Dur SSD

[Pascal Hambourg]

Le 24/01/2019 à 12:00, Eric Degenetais a écrit :

Effectivement, la durée de vie devient "acceptable" ... à condition de ne
pas se demander comment elle est obtenue : les SSD dits "de bonne qualité"
utilisent 3, 4, ... 8 fois la quantité de chip nécessaire à la capacité
qu'ils affichent, de manière à pouvoir les remplacer au fur et à mesure
qu'ils crament.


Source ?
Je n'ai jamais rien lu concernant un tel facteur d'over-provisioning.
Ça ne rime à rien, il suffit d'utiliser de la technologie SLC qui est 10 
fois plus endurante que la MLC et ne coûte pas 10 fois plus cher.

Re: Disque Dur SSD

[ajh-valmer]

On Thursday 24 January 2019 17:22:02 François-Marie BILLARD wrote:
> retour d'expérience, j'ai un SSD avec tout dessus, sous Debian depuis 4 
> ans et je m'en sert quotidiennement sans aucun problèmes à ce jour.

Merci à tous ceux qui m'ont répondu.

C'est fait, j'ai mis les 2 partitions sur le SSD, système et /home.

En tout cas, je ne reconnais plus mon ordinateur,
tant il est rapide par rapport à avant,
boot, upgrade, update, rsync... un vrai plaisir.

Je ne peux que conseiller de prendre un SSD,
si pas de panne ensuite, tant pis on verra :-)

Pas si grave si évidemment sauvegardes prévues
sur un autre disque.


> Le 24/01/2019 à 11:28, ajh-valmer a écrit :
> > Excuses, j'ai déjà posé un peu cette question,
> > La différence de rapidité est très sensible
> > entre un DD classique et un SSD, surtout au boot.
> > un SSD est réputé fragile si on y fait trop d'écritures,
> > (panne du disque possible, parait-il...).
> > Tant pis, je mets le système et le /home sur le SSD :
> > Est-ce dangereux ?

Re: Disque Dur SSD

[contact]

Bonjour

retour d'expérience, j'ai un SSD avec tout dessus, sous Debian depuis 4 
ans et je m'en sert quotidiennement sans aucun problèmes à ce jour.


Cordialement

François-Marie BILLARD
Le 24/01/2019 à 11:28, ajh-valmer a écrit :

Bonjour,

Excuses, j'ai déjà posé un peu cette question,

La différence de rapidité est très sensible
entre un DD classique et un SSD, surtout au boot.

un SSD est réputé fragile si on y fait trop d'écritures,
(panne du disque possible, parait-il...).

Tant pis, je mets le système et le /home sur le SSD :
Est-ce dangereux ?

Merci, bonne journée.

A. Valmer

Re: Disque Dur SSD

[Cyrille Biot]

Bjr

 >   un SSD est réputé fragile si on y fait trop d'écritures,
 >   (panne du disque possible, parait-il...).

A priori, il n'y a plus de problèmes avec les SSD nouvelles générations.
Et comme des fichiers de conf sont sur /home, ils est conseillé de le 
mettre aussi sur le SSD

Re: Disque Dur SSD

[Eric Degenetais]

Effectivement, la durée de vie devient "acceptable" ... à condition de ne
pas se demander comment elle est obtenue : les SSD dits "de bonne qualité"
utilisent 3, 4, ... 8 fois la quantité de chip nécessaire à la capacité
qu'ils affichent, de manière à pouvoir les remplacer au fur et à mesure
qu'ils crament. Donc effectivement, le disque tient dans le temps. C'est
une bonne vieille philosophie seventies : mon logement est isolé avec du
PQ,mais c'est sans gravité : je chauffe la moitié de la ville avec ma
chaudière et j’aligne les m3 de mazout comme un goret. En l'absence
d'inconfort immédiat on peut considérer que c'est bien, mais pour ma part
je considère ça comme du gaspillage pur et simple.
Question de point de vue

Cordialement.
__
Éric Dégenètais
Henix

http://www.henix.com
http://www.squashtest.org



Le jeu. 24 janv. 2019 à 11:53, elguero eric  a écrit :
>
> il y a quand-même pas mal de MacBook
> qui ont un SSD comme unique disque.
> j'en ai un depuis 5 ans. Maintenant, vu le prix
> de la bécane, c'est sans-doute pas le moins cher
> des SSD.
>
> e.e.
>
> Le jeudi 24 janvier 2019 à 11:45:31 UTC+1, Eric Degenetais <
edegenet...@henix.fr> a écrit :
>
>
> bonjour,
> dangereux non : tout disque a une durée de vie limitée, donc le risque
n'entre pas en ligne de compte, simplement l'utiliser comme home (beaucoup
d'écritures comme de lectures) va écourter sa durée de vie par rapport à
l'utilisation recommandée de disque système (peu d'écritures beaucoup de
lectures)
> Côté risque, ce qui est vraiment dangereux c'est de ne jamais sauvegarder
sa partition home
>
> Cordialement
> __
> Éric Dégenètais
> Henix
>
> http://www.henix.com
> http://www.squashtest.org
>
>
>
> Le jeu. 24 janv. 2019 à 11:28, ajh-valmer  a écrit :
>
> Bonjour,
>
> Excuses, j'ai déjà posé un peu cette question,
>
> La différence de rapidité est très sensible
> entre un DD classique et un SSD, surtout au boot.
>
> un SSD est réputé fragile si on y fait trop d'écritures,
> (panne du disque possible, parait-il...).
>
> Tant pis, je mets le système et le /home sur le SSD :
> Est-ce dangereux ?
>
> Merci, bonne journée.
>
> A. Valmer
>

Re: Disque Dur SSD

[elguero eric]

 il y a quand-même pas mal de MacBook
qui ont un SSD comme unique disque.
j'en ai un depuis 5 ans. Maintenant, vu le prix 
de la bécane, c'est sans-doute pas le moins cher
des SSD.

e.e.

Le jeudi 24 janvier 2019 à 11:45:31 UTC+1, Eric Degenetais 
 a écrit :  
 
 bonjour,dangereux non : tout disque a une durée de vie limitée, donc le risque 
n'entre pas en ligne de compte, simplement l'utiliser comme home (beaucoup 
d'écritures comme de lectures) va écourter sa durée de vie par rapport à 
l'utilisation recommandée de disque système (peu d'écritures beaucoup de 
lectures)Côté risque, ce qui est vraiment dangereux c'est de ne jamais 
sauvegarder sa partition home
Cordialement
__Éric Dégenètais
Henix

http://www.henix.com
http://www.squashtest.org


Le jeu. 24 janv. 2019 à 11:28, ajh-valmer  a écrit :

Bonjour,

Excuses, j'ai déjà posé un peu cette question,

La différence de rapidité est très sensible
entre un DD classique et un SSD, surtout au boot.

un SSD est réputé fragile si on y fait trop d'écritures,
(panne du disque possible, parait-il...).

Tant pis, je mets le système et le /home sur le SSD :
Est-ce dangereux ?

Merci, bonne journée.

A. Valmer


  

Re: Disque Dur SSD

[Eric Degenetais]

bonjour,
dangereux non : tout disque a une durée de vie limitée, donc le risque
n'entre pas en ligne de compte, simplement l'utiliser comme home (beaucoup
d'écritures comme de lectures) va écourter sa durée de vie par rapport à
l'utilisation recommandée de disque système (peu d'écritures beaucoup de
lectures)
Côté risque, ce qui est vraiment dangereux c'est de ne jamais sauvegarder
sa partition home

Cordialement
__
Éric Dégenètais
Henix

http://www.henix.com
http://www.squashtest.org



Le jeu. 24 janv. 2019 à 11:28, ajh-valmer  a écrit :

> Bonjour,
>
> Excuses, j'ai déjà posé un peu cette question,
>
> La différence de rapidité est très sensible
> entre un DD classique et un SSD, surtout au boot.
>
> un SSD est réputé fragile si on y fait trop d'écritures,
> (panne du disque possible, parait-il...).
>
> Tant pis, je mets le système et le /home sur le SSD :
> Est-ce dangereux ?
>
> Merci, bonne journée.
>
> A. Valmer
>
>