![]() |
Bienvenue invité ( Connexion | Inscription )
![]() |
![]()
Message
#1
|
|
![]() Macbidouilleur d'Or ! ![]() ![]() ![]() ![]() ![]() Groupe : Membres Messages : 5 195 Inscrit : 24 Aug 2010 Lieu : Saigon Membre no 158 214 ![]() |
Bonjour a tous
Apparemment nombreux sont curieux de vouloir connaitre les performances des différents SSD actuellement sur le Marché ,Crucial Vertex G Skill etc …Je propose donc a ceux qui en possèdent et qu ils le désirent ,de poster via QuickBench leurs Bench SSD Je commence avec ma 2CV A DATA S599 128 Sandforce Achat 4 days ago N oublié pas le test ,standart test numeric View qui est plus parlant concernant les débit entre 4k et 1024k PS je pense qu il serait pertinent pour ceux qui n ont fait aucuns entretien récemment (SecurErase,reconditionnement etc ) de préciser la date d achat et la vitesse de liaison négocié seulement pour ceux étant bridé en 1.5GB Ce message a été modifié par Kalm - 19 Nov 2010, 15:36. |
|
|
![]() |
![]()
Message
#2
|
|
Nouveau Membre Groupe : Membres Messages : 14 Inscrit : 31 Oct 2010 Membre no 160 719 ![]() |
Une question pour SartMatt, ou tout autre Sachem:
En quoi le nombre de passe peut-il changer quoi que ce soit pour un SSD? Sur un DD, les effacements en plusieurs passes se justifient pour la sécurité des données, mais sur un SSD?? Si en une passe, les cellules sont toutes effacées (0), à quoi bon en remettre une couche? Question corrolaire: La plupart des SSD actuels contiennent des réserves (pour le wear leveling et pour palier aux zones HS) de l'ordre de 5 à 10% de leur contenance. Les commandes d'effacement avec écriture (secure erase ou autres) s'appliquent-elles à la totalité des cellules physiques du SSD? Moi j'aurai tendance à dire non, dans la mesure où l'OS ignore les cellules réservées, seul le contrôleur les utilise. |
|
|
![]()
Message
#3
|
|
Macbidouilleur d'Or ! ![]() ![]() ![]() ![]() ![]() Groupe : Rédacteurs Messages : 32 233 Inscrit : 15 Nov 2005 Membre no 49 996 ![]() |
En quoi le nombre de passe peut-il changer quoi que ce soit pour un SSD? Sur un DD, les effacements en plusieurs passes se justifient pour la sécurité des données, mais sur un SSD?? Si en une passe, les cellules sont toutes effacées (0), à quoi bon en remettre une couche? Quelqu'un sur ce forum avait posté il y a quelques temps une étude faite par quelques chercheurs spécialisés dans le domaine du stockage, qui montrait que, comme sur un disque dur, on peut trouver quelques traces des anciennes données après un effacement (à cause d'une très légère rémanence), ce qui pourrait justifier plusieurs passes lorsqu'on veut rendre les données illisibles. Dans le cas d'une tentative de défragmentation de l'espace disque, la multiplication des passes améliore le résultat. En effet, après une écriture séquentielle, rien ne garanti que le contrôleur a optimisé au mieux cette écriture en groupant au mieux les cellules. C'est le fait d'effectuer plusieurs passes successives qui maximise la probabilité d'une défragmentation efficace. Les commandes d'effacement avec écriture (secure erase ou autres) s'appliquent-elles à la totalité des cellules physiques du SSD? Moi j'aurai tendance à dire non, dans la mesure où l'OS ignore les cellules réservées, seul le contrôleur les utilise. Dans le cas d'un secure erase, il y a simplement effacement, pas écriture. Cet effacement s'applique à l'intégralité des cellules, y compris l'espace de réserve. Dans le cas d'une réécriture de l'espace libre, toutes les cellules peuvent potentiellement être réécrites. En effet, le pool de cellules de réserve est un pool dynamique : au fil des écritures, les cellules affectées à ce pool varient. Lors d'une nouvelle écriture, l'opération optimale est bien souvent d'aller prendre une cellule du pool de réserve, d'écrire les données dedans et d'affecter au pool de réserve la cellule qui contenait l'ancienne version des données. Effectuer une réécriture de l'espace libre peut donc affecter l'intégralité des cellules d'un SSD. Ce message a été modifié par SartMatt - 24 Nov 2010, 05:13. -------------------- |
|
|
![]() ![]() |
Nous sommes le : 18th July 2025 - 13:04 |