Reprise du message précédent :
Par contre ces exclusions sont un peu bizarres    
 
https://image.noelshack.com/fichier [...] apture.png

Faut bien vivre.  

Alors je le défragmente mon SSD ou pas ?    
 

 
non
 

Pour quoi faire ?

 
Tous les deux jours pour t'assurer de le flinguer.

Lt Ripley -> pour vous faire peur, bien entendu    
C'est vrai que c'est con de proposer cela sur un SSD, à revoir  

 
ça montre qu'avec ce genre de logiciel, il faut être prudent.
 
j'ai testé hier, wise disk cleaner trouve 2,6 Go à effacer. j'ai sélectionné seulement 1 Go.  
Le reste, je n'y touche pas ; dans le doute.

Oui faut toujours être prudent.
C'est comme avec CCleaner, quand on se contente de faire des nettoyages basiques tout va bien, mais dès qu'on nettoie le registre on sombre dans le burlesque.

 
pas seulement avec le registre.
le suppression de fichiers en double peut aussi poser problème. Par exemple.

 
J'ai jamais eu aucun problème sur des dizaines de PC où j'ai nettoyé le registre avec CCleaner. En regardant vite fait, on voit qu'il nettoie bien des entrées qui n'ont plus aucun lieu d'être.

 
Le nettoyage du registre avec Ccleaner est gentil et complètement inutile, en plus d'être illusoire.  
Ceci étant, flashgordon avait donné un exemple de programme qui plante en nettoyant le registre avec Ccleaner. Je dis ça, je dis rien..

dites donc, vous voulez pas recentrer un peu et aller faire un topic nettoyage de windows pour les nuls sur clubic ou jeuxvideo.com ?

[/quotemsg]

Le contenu de ce message a été effacé par son auteur

 
Ben, pour ma part, je le fais tous les 3-4 mois... pour une raison simple : forcer les données à être déplacées, sinon, je fais vraiment très très très peu d'écritures dessus, vu que j'utilise un ramdisk. Clairement, ce n'est pas pour les performances, mais juste pour provoquer un remaniement de la répartition des données car il me semble que le wear levelling ne se fait qu'en cas d'écritures. Si on écrit très peu, je ne suis pas certain que les données ne soient déplacées, et la durée de rétention garantie n'est que de 3 mois (au plus défavorable)

Et pour les fragments qui bougent pas ? Tu les perds du coup ?    stop les conneries, en plus en déplaçant tu forces des écritures inutiles donc tu l’uses. Si tu allumes ton PC de temps en temps aucun risque de pertes.
 
D’ailleurs j’ai deja rebooté un os sur ssd après plusieurs mois voire années sans souci.

 
C'est le principe du SSD : les données bougent constamment.  
 
 

 
3 mois si ton SSD est stocké dans un environnement vers 60 degrés.
A température ambiante vers 20 - 23 degrés, c'est bien 2 ans.
(Et sans utiliser ton SSD, on parle de stockage)
 
Bref, tu psychotes pour rien.

 
Ah oui, quelle usure... 30 écritures complètes en 2 ans. Durées de vie estimée pour 3000 cycles : 200 ans ! C'est clair, c'est une usure vraiment sensible ^ ^
Pour les fragments qui ne bougent pas, il doit bien y en avoir, mais avec le logiciel qui va bien, tu peux faire en sorte qu'un max de données soit déplacé, et ca provoque, à priori, nécessairement le wear levelling, donc le SSD déplacera de lui même les données qui stagnent, justement pour que toutes les cellules vieillissent au même rythme.

 
Tu as une source ? parce que les 3 mois, il me semble que c'est le JEDEC.
 
(quant à 20-23 deg... en été, on est plutôt au double, sans soucis rien que pour l'ambiant, donc plus encore dans nos boitiers, mais il est vrai que c'est alimenté. Ceci dit, si on n'écrit pas des cellules, que le SSD soit alimenté ou pas, ca ne change rien : la capacité de grille peut se décharger)

Samsung SSD 970 PRO/EVO
https://www.computerbase.de/2018-04 [...] -pro-test/
 

 
tiens :
 
https://www.developpez.com/actu/852 [...] servation/
 
extrait :
 

 
2 ans à 25 degrés.
 
et si tu enlèves 20 degrés, tu doubles : 4 ans.
 
 

 
voila... et on parle de SSD non alimentés. Si ton SSD dépasse 20 - 22 degrés en moyenne sur 1 an sans être alimenté, ça sera beacoup.
 
 

 
si, ça change tout.
C'est un problème sur les SSD non alimentés. Voir le titre de l'article dont j'ai mis le lien au dessus :
 
 

 
Et quand bien même : tu as souvent du un SSD perdre certaines données à cause de ce problème? Perso jamais...
 
faut arrêter de psychoter.
 
et comme on te l'a déjà dit : défragmenter un SSD, c'est complètement..... comment dire... "con". (sorry)
Les données se déplacent constamment sur un SSD (C'est le mode de fonctionnement d'un SSD. Trim, tout ça... )
Et c'est pas pour rien si windows désactive automatiquement la défragmentation quand tu installes windows sur un SSD.
Défragmenter un SSD, c'est comme si tu lavais ta voiture alors que tu viens de la laver.

 
 
https://www.anandtech.com/show/1267 [...] -nvme-ssds
 
par rapport au 960 EVO:
 
garantie qui passe de 3 à 5 ans
endurance +50%  
+5% en conso
perf en hausse  
 
et prix officiel un chouia en dessous des 960 EVO (qui date de novembre 2016), ça ne baisse pas très vite et ça reste sensiblement plus cher que les SSD Sata ^^
 
 
 

Ca serait bien que Crucial nous sorte un SSD M.2 PCIe, sans ca les prix sur ce segment ne baisseront que lentement.
Déjà que je trouve qu'il n'y a pas de raison qu'il ait de différence de prix entre les M.2 SATA et M.2 PCIe, la flash c'est exactement la même et le contrôleur pas beaucoup plus complexe que celui en SATA, bon le firmware par contre... mais quand même.

Pour le fun
 
Le ruler d'Intel , 8TB, 5000€
https://geizhals.de/intel-ssd-dc-p4 [...] at&hloc=de
 

 
Dommage il n'y a pas de photo du PCB  

Les perfs du 970 EVO semblent en retrait (cf test sur storagereview.com)
Par contre, le 970 PRO  

 
Le même avec un 0 en moins dans le prix et c'est nickel.  

 
 
celui de computer a l'air plus positif (j'ai pas maté tous les graph ceci dit)

 
 
Bon, alors pour répondre clairement : la constitution de la mémoire flash, ce sont des charges stockées sur une grille flottante (Wikipedia (pour faire simple)). Donc deux cas de figures :
- soit le SSD n'est pas alimenté, et ca se décharge forcément, ce qui donne la durée de rétention. Avec les forts champs électriques appliqués lors des écritures, il se crée des défauts dans les oxydes de part et d'autres de la grille flottante, et donc la durée de rétention diminue avec le nombre de cycles. Ceci dit, le JEDEC garantie 3 mois (... même en fin de vie, mais rien n'est dit sur la façon dont ca évolue avec le temps, ceci dit, je suis certain qu'on trouve de la littérature sur google.scholar)
- soit le SSD est alimenté (premier sous cas) : s'il y a une ré-écriture d'une cellule, la durée de rétention est ré-initialisée. Pas de soucis, les données seront conservées ... tant que la grille flottante n'est pas déchargée. Dans ce cas de figure, la décharge peut se faire en moins de 3 mois (ou plus selon le nombre de cycle), car la température du disque, en usage, est quand même généralement bien au dessus des 20°C (et comme tu l'as indiqué +5°C -> durée divisée par deux. Avec 28°C pour le SSD, on est donc certain que si le disque est allumé en permanence, la durée peut chuter à 1 mois environ, et encore bien moins en été lorsque la température est plus haute). Personnellement, j'ai écrit 11 To sur mon SSD de 512 Go en 3 ans (SSD-Z). En pratique, les écritures ne sont pas du tout régulières mais bon, ca fait 300 Go/mois environ, soit un bon demi SSD par mois. Dans les conditions estivales, je suis certain que la quantité d'écriture ne permet pas de renouveler le contenu de chaque cellule. Et puis, si on veut aller au fond des choses, la durée de rétention est aussi fonction du nombre de lecture d'une cellule et des tensions appliquées à la cellule...
- soit le SSD est alimenté (second sous cas), et certaines cellules n'ont pas été ré-écrites depuis un moment. Normalement, c'est le contrôleur interne qui se charge de tenter d'identifier les cellules écrites depuis le plus longtemps pour les déplacer tout seul lorsqu'il se "tourne les pouces" : c'est le wear levelling (Wikipedia (pour faire simple).  
 
Donc en conclusion, tout dépend de l'algorithme interne du SSD à gérer convenablement le wear levelling. Je te l'accorde, il n'y a pas de cas d'école où cet algorithme a failli au point que ca saute aux yeux (sauf peut-être pour les cas où la table des partitions a été touchée, ce qui est statistiquement très rare). Cependant, le nombre d'erreurs en lecture est justement l'image du nombre de cellules qu'on n'a pas pu lire correctement, entre autre parce que pas rafraichies assez souvent (vieillissement prématuré à cause d'un défaut) ou par un soucis dans le transport entre la mémoire et le controleur. Et encore, pour générer une erreur de lecture, il faut aussi que les codes de correction d'erreur n'aient pas pu permettre de reconstituer l'information.
 
Je t'invite à regarder combien vaut ton RAW READ ERROR RATE (pour SSD-Z) ou TAUX D'ERREUR EN LECTURE (crystal disk mark), si la donnée est disponible (ca dépend des constructeurs).
 
Donc oui, on a de la perte de données et ce n'est pas du psychotage (mais il y en a vraiment très peu normalement...). Dans mon cas, sur le Crucial 512 Go sur lequel j'applique ce "traitement", j'ai eu 2 erreurs irratrapables en 3 ans mais je n'ai accès au taux d'erreur interne (certainement plus élevé, mais j'ignore si le SMART le permet, en tout cas, pas sur mon SSD crucial). Ceci dit, mon SSD fonctionne à merveille, et tous les voyants sont au vert, parce que les machines sont dimensionnées avec un certain taux d'erreurs acceptables. Par exemple, sur un port PCI-e, c'est un BER de 1e-12 (soit un bit sur 10^12 qui risque d'être mal interprêté...), sur un bus QPI, c'est 1e-14... et sur nos mémoires flash, c'est pareil : il y a un taux d'erreur pour chaque cellule. Et quand on y réfléchit, c'est fréquent... en moyenne 14h sur un bus QPI (mais le plus souvent, ca passe inapercu, car l'erreur est détectable) par exemple, mais le plus souvent, il y a des méthodes pour rebondir (soit reconstruire les données, soit les redemander).
 
Et pour répondre à ta question, de la flash qui perd son contenu, oui, j'ai connu, notamment des clefs USB, car elles n'ont pas d'algorithme de wear levelling, justement. Et donc au bout d'un an connectée sporadiquement en lecture, les fichiers les plus anciens était corrompus. Un formatage, et ca repartait.
 
Etant donné :
- que j'ai des documents présents depuis ... le début du SSD (3 ans) et qui n'ont JAMAIS été modifiés,  
- que j'ai un très faible taux d'écriture (merci le RAMDISK pour les fichiers temporaires)
- que je n'ai pas la main sur l'algo du wear levelling
... je préfère en provoquer une écriture de temps à autre en utilisant différentes méthodes de défragmentation (pour être quasi certain que les données changent d'adresse). Cela n'a aucun impact sur la durée de vie des cellules, vu que c'est 3-4 fois par an soit 10-15 cycles depuis que j'ai le SSD. Apparemment, il en est à 35 : il peut vivre 300 ans à ce rythme en théorie. D'ailleurs, 35*512 Go = 17 To... donc le wear levelling n'a pas tout à fait doublé le nombre d'écriture des cellules.
 
La seule façon de trancher de l'intérêt de la manip, ce serait de comparer les RAW READ ERROR RATE pour un parc de machines, avec ou sans ces déplacements volontaires de fichiers. En attendant, je ne prends pas le risque.

 
Quel genre d'erreur?
et tu considères que c'est forcément la faute de la mémoire flash?  
pourquoi ça ne serait pas le contrôleur? Ou simplement windows?
Mieux : la défragmentation que tu appliques avec wise disk cleaner pourrait être à l'origine du problème.
 

 
non tu ne réponds pas à la question.  
Je parle de SSD, pas de clé USB. Il y a autant de points communs entre un SSD et une clé USB qu'entre un moteur diesel et un moteur essence.  
 
Donc je te repose la question : est-ce que tu as déjà vu quelqu'un perdre des données sur un SSD?
Tu es à peu près le seul à défragmenter tes SSD. Personne ne fait ça, et personne n'a de perte de données.

Défragmenter son SSD, c'est comme faire la vidange de sa voiture électrique.

 
Ce sont les mêmes techologies de puces NAND flash sur les SSD et les clefs USB, désolé pour toi. Donc oui, ca meurt. Mais sur un SSD, tu as de l'over-provisioning, donc ce n'est qu'en jetant un oeil au SMART, et si c'est indiqué, que tu peux observer combien tu as de cellules mortes. Avec le SSD, la plupart du temps, ca passe totalement inaperçu, car les algos de correction d'erreur font qu'on peut restituer les donner, et le controleur peut alors condamner les secteurs qui ont posé soucis, et utiliser ceux en excédent dans l'over-provisioning.  
 

 
Rectification : personne ne remarque les pertes de données.
 
Comme suggéré, tu as regardé ton SMART avec crystal disk info ? ou SSD-Z ? Histoire de voir ce que raconte ton SSD...

 
c'est pas aussi simple..  
 
https://superuser.com/questions/919 [...] and-an-ssd
 

 
Tu la vois la différence entre clé USB et SSD?
 

 
Si je perdais des fichiers, je l'aurais remarqué un jour ou l'autre et ça aurait certainement occasionné un méga plantage de windows.
 
Pour l'état de mon SSD :
 

 
c'est gentil de t'inquiéter pour mon SSD  
 
et tu n'as pas répondu à ma question : quelles étaient ces 2 erreurs sur ton crucial M512?  
concrètement.  
 
 

DayWalker II -> On peut voir ce genre de chose via les données Smart ?    
Perso à chaque fois que j'ouvre un logiciel qui fait ça, je ne vois rien - ou tout du moins des chiffres qui ne me racontent pas grand chose. Et avec en permanence un bilan global de santé positif.
 

 
Normal, ton SMART ne retourne pas cette information... le mien si. Par contre, le tient semble retourner le taux d'erreurs ECC et le uncorrectable error count (mais apparement, le champ est vide... donc on ne peut pas dire s'il est bien géré)
 

 
tes 2 erreurs ne sont peut être pas dues a une défaillance des cellules.  

 
Comme tu l'indiques, c'est le controleur qui diffère et qui "sauve les meubles" dans le cas des SSD pour les rendre très nettement plus robustes... pas le support de stockage, qui reste une (ou plusieurs) grille flottante chargée, avec sa durée de rétention.

+1
Câble SATA peut-être

 
A priori, non, dans ce cas, ce serait plutôt une erreur de type Ultra DMA CRC Error Count (mais le champ est vide, pas à 0)
 
EDIT : les codes de parité CRC permettent justement de détecter les coucis de communications (mais pas de corriger : il faut redemander les données)
 
EDIT 2 : RAW READ ERROR RATE, ca veut dire "erreur de lecture des données brutes", donc c'est une erreur de lecture de cellule, du moins entre la NAND et le controleur.

 
je te donne la réponse de crucial :
 
http://communaute.crucial.com/t5/D [...] td-p/10901
 

 
 
Je pense que cette fois c'est clair pour toi.

Et moi qui pensais garder un ssd dans un tiroir en tant que copie de sauvegarde pérenne au cas ou mon ssd actuel lâche, je crois que c'est râpé si je ne le rebranche pas sous peu