Je finis par regretter mon achat .
J’ai hésité entre un WD 2 To tournant à 7400 tm
on dira ce qu’on voudra mais les disques mécaniques sont certes plus lents, mais beaucoup plus fiables dans le temps. Les disques SSD tout comme les barrettes mémoire sont donnés pour un nombre de cycles de lecture écriture limité … même si ça fonctionne beaucoup plus longtemps que prévu.
Nous n’avons pas obtenu le même résultat, malgré à peu près les mêmes expériences.
Les outils de réparation et d’avertissement sont disponibles chez les vendeurs de SSD ou bien ils sont disponibles avec le système d’exploitation, comme avec Linux, par exemple.
Bonjour,
Tout dépend de l’utilisation qu’on veut en faire et, comme pour les disques durs, il y a des modèles différents de SSD en fonction de cette utilisation.
Ne pas oublier non plus que la technologie évolue vite et ce qui est vrai aujourd’hui ne le sera pas forcément demain.
Pour se faire une idée (article de 2022 mis à jour en avril 2024):
bb
Le logiciel Crystal Disk Info est très bien pour surveiller les HDD, SSD sous toutes versions , beaucoup d’infos dont le pourcentage d’usure des SDD
Je remarque que les SSD M2 NVME ( pour le moment reste à 100% ) s’usent moins vite que les SSD Sata ( descendent assez rapidement autour des 95% après baisse moins vite ) , entre les deux les SDD M2 Sata …
et WD qui n’a pas tenu bien longtemps depuis il est dans un boitier externe …
Pour corriger quelques imprécisions:
Non. Ça ne concerne que les mémoires basées sur des techniques de mémoire permanente E²PROM ou dérivées (Flash). Les barrettes mémoires RAM MOS non permanentes n’ont pas de limite pratique en lecture écriture même s’il y a une limite théorique.
De même, les mémoires permanentes de MRAM (magnétiques) sont pratiquement inusables mais elles ne sont utilisées que dans quelques applications. Le processus industriel de fabrication est encore aujourd’hui plus coûteux ce qui explique qu’elles ne se sont pas imposées face aux mémoires flash.
Sur l’usure des SSD (flash) : les contrôleurs optimisent l’écriture pour éviter la dégradation des mêmes blocs de cellules (et peut-être, les drivers aussi). Mais il y a une limite et à un moment, on assiste à des pertes d’intégrité qui ne sont pas corrigeables. Le SSD est mort et en général, la conséquence est globale. Comme indiqué par certains, il y a des programmes associés aux SSD qui permettent de mesurer le niveau « d’usure » du SSD (Samsung Magician chez Samsung) afin de déterminer quand changer le SSD.
Il est très peu probable que cela vienne d’un problème du SSD. Je pencherais plutôt pour des erreurs de manipulation.
En cas de problème de SSD, on aura plutôt des pertes d’intégrité sur une partie des fichiers ou plus grave sur les zones de description des fichiers et là, ce ne sont pas quelques fichiers qui disparaissent mais la structure du système de fichiers qui se corrompt avec des résultats plus dramatiques que la simple perte de fichiers ou de répertoires.
Un simple test de la structure du système de fichier devrait pouvoir vous en dire plus sur son intégrité (sous Windows, exécutez Chkdsk).
Je confirme que dans l’état actuel des techniques, il faut faire des sauvegardes régulières sur des disques magnétiques classiques (et si possible, plusieurs).
Comme le dit @georgesgiralt, il faut (faudrait car ce n’est pas toujours simple) configurer son système et ses applications pour que ces dernières n’utilisent pas le SSD pour leurs fichiers temporaires (certains programmes n’arrêtent pas de lire et d’écrire de tels fichiers). Il est préférable que ces fichiers soient écris sur un disque dur classique ou sur un autre SSD sacrifié et réservé à cet usage si on a besoin de rapidité.
Bonjour
J’ajouterais que - sauf erreur - il ne faut pas défragmenter un SSD (contrairement à un DD classique)
Sous Linux c’est « enfantin ». On crée un volume groupe LVM avec les disques nécessaires (mécanique, SSD, NVME, etc…) et dessus on crée les volumes logiques chacun destiné à un usage particulier et mis sur son volume voulu.
Ensuite, il suffit de mettre le système à un endroit, les fichiers temporaires à un autre, les données utilisateur sur un troisième, etc…
Coté Windows on doit pouvoir mais c’est sûrement plus compliqué, comme toujours.
Il faut préciser que mettre les fichiers temporaires sur un SSD augmente TRÈS fortement les performances. Donc, sous Linux, on sacrifie un tel SSD qui ne contiendra que cela et sera remplacé quand mort sans conséquences gravissimes. Surtout que le prix d’un NVME ou SSD de faible capacité est très faible.
Tout a fait faut désactiver la défragmentation automatique à la pose
Temps que c’est bleu Bon ou Correct pas de soucis
Pas plus compliqué sous Windows que sous Linux. Mais ça ne règle pas le problème de savoir dans quel répertoire un programme écrit ses données temporaires. Et sous Windows, beaucoup de programmes ne respectent pas la logique du système d’exploitation et ne vous laissent pas le choix.
Sinon, une autre solution mais qui n’est pas généralisable et ne fonctionne que pour certaines applications est d’utiliser des disques virtuels en RAM pour les fichiers temporaires. On a ainsi le meilleurs des deux mondes : rapidité (plus rapide que le SSD) et pas d’usure.
Toutafé
Compte-tenu de l’usure des SSD, dois-je comprendre que c’est pas trop une bonne idée que de vouloir mettre la partition Linux Swap sur un SSD ?
si la RAM est suffisante la partition SWAP ne devrait pas servir beaucoup
@georgesgiralt
J’aime bien ton idée de LVM mais j’ignore s’il faut réinstaller Ununtu?
Ah ! Tout dépend.
Si tu ajoutes du disque, tu peut utiliser ton Linux tournant pour créer/configurer/formater ton LVM puis du dump/restore pour déplacer les données (ne pas oublier de modifier le fstab…) et un petit reboot à la fin.
Tu peux aussi faire le même type de manip sur un disque externe, et une fois que tes données y sont, incorporer ton disque dur d’origine dans ton volume groupe et faire du pvmove pour rapatrier tes données dedans.
Mais ce sont des manips compliquées qu’il vaut mieux avoir testées sur un système de test avant de se lancer sur un système « en production »…
Merci pour ces infos.
Avec tous ces renseignements ultra-précis je vais pouvoir revérifier mon SSD Crucial, installer un LVM’…
Avec Linux, c’est la partition /tmp, mais aussi /var/tmp, qui sont les partitions attitrées pour cela. Mais rien n’empêche d’en prendre une autre.
C’est exact ! Mais SWAP n’est pas sous le contrôle de l’utilisateur. Toutefois, cette partition gagne à être sur SSD en raison de la rapidité, qui est un facteur décisif ici. En outre, les données ne sont jamais stockées bien longtemps dans SWAP, le cas de « hibernate on disk » est spécial. De nos jours, il vaut bien mieux avoir assez de RAM, afin que le SWAP ne soit utilisé qu’exceptionnellement.
Un débutant aura ses problèmes avec ça. Mais c’est une bonne solution.