Reprise du message précédent :
Est ce qu'il existe un logiciel de type CristalDiskInfo pour connaître la bonne santé d'un SSD ?

En GUI : GSmartControl.
En CLI : smartctl.

(smartctl = smartmontools)

Super, merci.
Difficile d’interpréter le résultat quand on y connaît pas grand chose.

J'ai mon petit Samsung 960 EVO NVMe (250 Go) depuis un an maintenant et j'en suis toujours aussi content    
 

J'aime bien le NVMe  

 
Sous plasma: DiskMonitor https://github.com/papylhomme/diskmonitor
 
Après c'est pas un mal non plus d'utiliser le service smartd avec notification bureau et mail même si les fabricants n'intègrent pas tous les paramètres utiles dans les données S.M.A.R.T.
 
Personnellement sur mes disques, smartd fait un short test toutes les nuits et un long toutes les semaines. Ça m'a déjà été utile avec un SDD (alors même que /tmp /swap tous les deux chiffrés à la volée, sont sur le HDD, /var /home (chiffré) aussi sur HDD)). Avec les SSD pour le grand public, on n'est jamais trop prudent. D'où la nécessité des sauvegardes    

Sympa l'applet ! par contre je n'arrive pas à la redimensionner ! :\

Bonjour

gsmartcontrol est top oui, ou en ligne de commande c'est simple aussi mais moins convivial.

Mon ssd intel est toujours à 100% de vie par exemple.

et nvme-cli pour les SSD NVMe  
 
https://packages.debian.org/stretch/nvme-cli
 

 
Je viens de lancer les même commandes sur mon intel 600P ( INTEL SSDPEKKW256G7, 256 Go, il a 1000 redémarages et un peu moins de 4000h de fonctionnement),
j'obtiens (seulement) en lecture : Timing buffered disk reads: 1710 MB in  3.00 seconds = 569.90 MB/sec
et même carrément en écriture : 10737418240 bytes (11 GB, 10 GiB) copied, 42,522 s, 253 MB/s
Ceci dit cela reste déjà énorme par rapport à la plupart des ssd.
 
NOTE : A l'achat j'avais 720 Mo/s en lecture et 490 Mo/s en écriture , ce qui était normal / chiffres du net pour ce disque. Faudra que j’enquête pour comprendre la forte baisse des 2 vitesses.
 
EDIT: j'ai édité ce message car mon ssd c'est un 256Go en fait, pas un 128 Go comme j'avais indiqué avant.. du coup mes chiffres sont encore plus faiblards par à ceux du net (1570 en read... 540 en write)...

Ça fait quand même une sacrée différence  
 
https://www.hardware.fr/articles/90 [...] ances.html

Je viens de penser à une piste : J'ai changé de distribution entre mes 2 mesures. Si cela se trouve je n'ai pas le bon pilote sur la nouvelle. Vous utilisez quoi comme pilote vous tuorhuor ?
Edit : Mes premières recherches me font penser que Intel a bien du mal assurer une compatibilité de ses ssds avec linux.
Apparement, il y a même eu un bug entrainant de la corruption de données, dans le cas d'utilisation du système de fichier XFS, que je n'utilise pas personnellement, mais bon... ( La référence est là : https://bugzilla.redhat.com/show_bug.cgi?id=1402533 )

EDIT : Pour le moment concernant mon driver, j'ai juste trouvé ( par la commande " lspci -vvv | grep Intel " ) :

 ... ce qui ne m'avance pas beaucoup...

les options de montage peuvent aussi avoir pas mal de conséquence sur les perfs.

Extrait de mon fstab (j'ai juste enlevé les uuid) :
 

marrant j'ai toujours privilegié intel (pour tout)  justement pour les compatibilité linux  (j'deconne pas hein)
 tes montage ext4 tu met pas de noatime   relatime et autre joyeuseté?
chez moi par exemple :

le swap gaffe si t'as pas beaucoup de memoire ça peut vite faire beaucoup d'ecritures et ralentir les acces pour le reste (et accelerer le vieillissement de ton SSD par la meme un peu.) le swapiness se regle
et si t'as plein de ram ben un petit

peut alleger encore les cycles  d'ecritures sur le SSD

je me suis bien basé sur ça pour parametrer: https://www.linuxwolfpack.com/linux-ssd-lm17.php

Chez moi j'ai toujours ces deux options pour le montage des partitions d'un SSD :
* noatime : car pas nécessaire dans le cadre d'un PC, avec un gain non négligeable en perf
* discard : pour le trim
 
Tu gères le trim manuellement ?
 

suivant les distrib discard dans le fstab  fonctionne ou pas...si ça marche pas on claque un fstrim dans un cron cron weekly et hop

L'option discard n'est pas recommandée pour l'immense majorité des scénarios. La best practice c'est via un cron. Y'a un timer tout prêt pour ça dans systemd.
Réf : https://forums.freebsd.org/threads/ [...] ost-328912

Le discard ça dépend l'usage, on en a déjà parlé ici.
Pour une utilisation normale, c'est mieux de le faire à la volée, c'est transparent, pour un usage suppression régulières de gros fichier il vaut mieux le faire à un autre moment pour que cela soit transparent.
 
Perso c'est discard sur tous mes ssd.  
 
Et idem j'avais aussi tendance à choisir intel jusque là pour la sécurité. Mais depuis qu'ils ont arrété les ssd avec SLC, je prends aussi les autres marques.

En effet : "Ext4's discard feature can be useful, but only in very highly specialized use cases"
Et je pense que le grand public ne fait pas partie de ces scénarios "highly specialized use cases".

comme dit plus haut sans discard il faut un appel régulier à fstrim (cron ou autre)

En effet...  
 
Les préco ont changeaient entre temps, Il faut que je mette à jour.
 
https://wiki.debian.org/SSDOptimiza [...] ilesystems

Moué pas du tout convaincu.  
D'un autre côté avec les contrôleurs, on ne sait même pas s'ils ne le font pas déjà la volée quand ils le jugent nécessaire.
 
JE préfère que le trim se fasse au moment opportun, c'est à dire la suppression du fichier, et pas à un instant T ou si ça se trouve rien ne s'est passé depuis la dernière fois.
Donc avec un trim par cron on prend le risque de faire des trim pour rien (pas de risque, mais je ne vois pas l'intéret) ou d'en faire trop peu et de perdre en perf entre deux trims.
 
Pour moi le trim par cron c'est au contraire pour un usage de serveur qui tourne tout le temps et quand on sait quand on peut planifier la chose.
Pour un pc portable allumé éteint etc, c'est prendre le risque que le trim ne passe jamais ou se lance pour une grosse action sur batterie.  

 
Genre exemple simple, tu supprimes une vm de 50go.
Avec discard, tu vas avoir 2/3s de freeze à ce moment précis (je n'ai pas le délai précis ça dépend des conditions, mais bon ça se fait en live).
JE trouve ça logique.
 
Sans discard, c'est au moment ou la tâche cron est planifiée que cela va se faire, donc soit il faut que le pc tourne pour rien à certains moment (usage d'un serveur), soit si tu le planifies toutes les Xh (quel est l'intéret????), ça peut très bien se produire en plein jeu ou traitement lourd.  
 
Bref pour moi c'est tout à fait l'inverse, le trim par cron c'est un usage très spécifique qui ne convient qu'à des machines ayant tendance à tourner souvent et surtout ayant des grands moment d'idle durant lesquels tu peux le planifier (serveur/pc@home que tu laisses tourner toute la  journée)
 
Pour un individu lambda éteignant son pc et ou ne l'allumant pas en continue c'est pour moi contre productif.

ouais bon, il y a un peu de lecture... c'est plus très clair tout ça...
 
https://www.spinics.net/lists/raid/msg40916.html

Personnellement, j'aurais tendance à faire confiance à Ted Ts'o de part ses contributions (il a écrit une bonne partie d'ext4fs et maintient en plus les outils pour ext2/3/4) et son expertise.

c'est noté    

2012...
À l'époque ou le trim n'était pas forcément supporté par les contrôleur sata ou mal.

Tu aurais un lien?

je pense qu'il palais de ce lien posé plus haut:
https://forums.freebsd.org/threads/ [...] ost-328912

Il y en a qui utilisent toujours btrfs sur ssd ou a déconseiller en raison des perf ? vs XFS ?

up, je suis sur ssd, j'ai btrfs, ya des bonnes options a mettre pour ce système de fichier ?

 
Je crois que je viens d'avoir ma première panne incompréhensible de ssd.  
Je ne suis pas sûr que ça soit lui en cause, mais je ne vois pas d'autre raison logique.  
 
On peut imaginer que ça soit backintime qui soit en cause, mais vu que je sauvegardais un répertoire /home/X qui n'était pas le répertoire de l'utilisateur courant ça me parait peut probable. Sauf s'il s'est foiré dans ses montages.  
 
En gros durant une sauvegarde, j'étais connecté à distance sur le serveur via x2go, et subitement j'ai vu que des les raccourcis dossiers étaient foirés. J'ai voulu ouvrir le terminal ==> impossible, j'ai testé de lancer des applications non plus.
J'ai rebooté, ça bloque au boot...
 
En mode kernel safe ça boote encore, mais la partition / semble foirée. (partition qui est sur le ssd).
J'ai testé depuis un livecd, les partitions sont bien toujours lisibles tant le / que le /home (qui est sur un disque dur standard). IL faudrait que je vérifie le contenu des partitions mais vu les symptômes ça semble plus être un pb sur la partition /.  
 
Les infos smarts du ssd semblent pourtant correctes (il reste 82% de vie), et j'avais prévu le coup avec une partition de seulement 30go sur les 120 dispo donc le ssd ne peut se remplir.  
J'avoue ne pas vraiment comprendre ce qui s'est passé et si le ssd est en cause.

un foirage de table de partition pour une raison X?
si y'a aucun message d'erreur du ssd (y'a pas de soft de test specifique du constructeur?) la seule solution est reformater ton / restaurer son contenu et attendre en croisant les doigts...
si c'etait la logique du SSD qui partait en couille tu n'aurais plus acces a aucune des partitions dessus non?
t'es en quoi btrfs ext4 autre?

Non non le ssd est toujours accessible. comme dit avec un live cd je peux toujours y accéder et accéder au contenu
Je peux toujours booter dessus en mode kernel safe, mais dpkg est hs et fonctionne mal, plein de trucs ne fonctionnent plus.
J'ai testé un "clean" en mode safe, il a commencé à dégager des programmes ne me servant plus, et il est resté bloqué à une action sur la bd. Donc certaines choses semblent corrompues ou détruites.
Fsck ne trouve rien tout est ok pour lui.

C'est de l'ext4.

Je n'arrive vraiment pas à comprendre ce qui a pu se passer. Si le ssd avait laché je n'aurais plus rien de fonctionnel, là c'est boiteux, mais y a quelques trucs qui bootent, le kernel safe boote, mais impossible de lancer la couche réseau par exemple, et au boot normal j'ai plymouth, j'arrive à voir défiler quelques erreurs, et je vois qu'il n'arrive pas à lancer la couche réseau par exemple, donc y a plein de truc de cassé. Et au final je n'ai jamais la mire de connexion.

Tu dis que tu accèdes toujours à tes fichiers. D’accord, mais tu entends quoi, par là ? C’est juste que dans un gestionnaire de fichiers ou un ls, tu vois la liste des fichiers tout comme il faut, ou tu arrives à lire le contenu de ces mêmes fichiers ?
 
Non, parce que si la liste est OK (et donc aussi la table de partitions), mais que les fichiers sont foutus en réalité… T’iras pas bien loin.

Je sais je n'ai pas eu le temps de voir encore réellement.
Le kernel boote donc tout n'est pas corrompu. Après ce que j'aimerais c'est savoir ce qui c'est passé. Si le ssd est bon à jetter ou si c'est un bug du pgm de sauvegarde...

Les nouvelles du front.
Le /Home est intacte.
Par contre le / semble totalement hs, je suis en train de réinstaller en gardant mes partitions, et sur le / il ne me trouve que 685mo... (avant que je ne formate c'est ce qu'il disait comme contenu...)

Sachant que tout semble ok, je ne pense pas que le problème provienne du ssd, je me dis que le logiciel de sauvegarde a dû faire une connerie dans les montages ce n'est pas possible autrement...

EDIT: réinstallation tout est ok... Le ssd ne semble bien pas mort et semble 100% ok...

Salut,
Un question concernant le TRIM. Mon système est chiffré selon cette méthode : LVM on LUKS
Dans mon fstab, j'ai bien l'option discard sur mes deux partitions, mais ce week-end lors d'une réinstall, je vois que dm-crypt ne le support pas par défaut et qu'il faut le spécifier avec l'option :allow-discards dans la config du bootloader https://wiki.archlinux.org/index.ph [...] ives_(SSD)    
Si je fais lsblk --discard, j'ai :

Je suppose que les valeurs 0B pour MyVol-root et MyVol-home veulent dire que le TRIM n'est pas activé ?

https://wiki.archlinux.org/index.ph [...] drive#TRIM

J'ai ça sur ma machine avec chiffrement :

Apparemment oui il te manque un point de conf quelque part  

J'ai ça :

 
J'ai ça dans mon syslinux.cfg :

Je devrais donc mettre :

là j'avoue ne pas pouvoir t'aider, je suis sur une Debian avec grub