Vos Bench SSD via QuickBench4 ici, Cherche QuickBench de SandForce après longue période d utilisation i

[Kalm]

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.

[Crazy Vessel]

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.

[SartMatt]

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.

[Crazy Vessel]

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.

J'aurais bien aimé jeter un oeil sur le boulot de ces chercheurs, j'ai un peu cherché, sans succès. Si tu retrouves... En terme de rémanence, une différence de niveau entre deux états magnétiques, même d'intensité infime, peut effectivement être détectée après plusieurs effacements (cas des DD), mais ne connaissant pas (encore!) la méthode "physique" d'écriture d'un bit sur une cellule de SSD, je reste dubitatif.

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.

Je m'étais peut-être mal exprimé: "effacement avec écriture" je voulais dire effacement remise à zéro de la cellule, ou une passe (par opposition à un effacement standard de l'adresse sur un DD).

Cet effacement s'applique à l'intégralité des cellules, y compris l'espace de réserve.

Là aussi, je reste dubitatif. Bien que l'espace de réserve soit dynamique (on ferait mieux de parler de "nombre de cellules" réservées plutôt que d'"espace"), la probabilité qu'il reste un seul secteur non écrit sur le SSD diminue au fur et à mesure de son utilisation après qu'il fut plein. Sur un SSD plein ou presque qui est utilisé depuis un moment (réécritures), il est tout à fait possible que 99,9% des cellules soient porteuses d'information. Si c'est bien l'OS qui dirige les opérations dans le cas d'une passe à 0 (ou plusieurs), ou dans le cas d'un secure erase, je doute que le contrôleur donne accès à 100% des cellules. Je pense au contraire que le contrôleur va continuer à faire bêtement son travail, et une partie (les 5 ou 6% de réserve en l'occurence) sera, AMHA, ignorée de la commande d'effacement.

Ce message a été modifié par Crazy Vessel - 24 Nov 2010, 10:05.