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.

[SartMatt]

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 les mémoires flash, les bits sont stockées sous forme de charge électriques, avec 2 à 8 niveaux de charges possibles par cellule selon le type de mémoire.
Je t'avoue que je suis moi aussi assez dubitatif sur la possibilité d'une rémanence suffisante pour relire les données, surtout sur les mémoires MLC (celles à plus de 2 niveaux de charge).

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).

Justement, sur un DD, il n'y a pas de notion d'effacement.
Sur un DD, on ne peut faire que deux types d'opérations sur un bit : lecture ou écriture. L'effacement consiste simplement à écrire par dessus les données existantes.
La commande ATA Secure Erase effectue donc une réécriture sur l'ensemble du disque (par contre je sais pas si c'est juste des zéros, où si ça écrit plutôt des données aléatoires).
Les logiciels d'effacement de données font de même, donc donnent le même résultat.

Sur un SSD par contre, il y a trois opérations possibles sur une cellule : lecture (opération qui s'effectue sur toute une page à la fois), programmation (qui s'applique également à toute une page, et qui consiste à faire passer certaines cellules de la page de l'état 1 à l'état 0), effacement (qui s'applique à un bloc de plusieurs pages, et qui consiste à repasser de l'état 0 à l'état 1 toutes les cellules du bloc). Une écriture de données se fait soit directement avec une programmation, si la cellule est vierge, soit avec un effacement puis une programmation si la cellule n'est pas vierge.
La commande ATA Secure Erase effectue uniquement un effacement, ce qui est du coup très rapide, et fait qu'après l'opération toutes les cellules sont considérées comme vierges par le contrôleur.
Les logiciels d'effacement de données par contre, ils vont commander des écritures. Ce qui revient donc en fait à faire des effacements puis des programmation, et donc les cellules ne seront pas considérées comme vierges par le contrôleur.

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.

Dans le cas du secure erase, ce n'est pas l'OS qui dirige les opérations. Il envoie juste la commande ATA Secure Erase au SSD, et le contrôleur déclenche alors l'effacement de toutes les cellules.
Dans le cas d'une passe d'écriture avec des 0, ça va probablement affecter une partie des cellules de l'espace de réserve, vu qu'il est dynamique : quand on écrit sur un secteur mappé sur une page non vierge d'un bloc donné (A), il est relativement probable que, au lieu d'effacer puis programmer le bloc A, le contrôleur aille programmer un bloc B pris dans l'espace de réserve, puis marque le bloc A comme étant un bloc de réserve (ce qui déclenchera son effacement durant une phase de garbage collection). Cette rotation de l'espace de réserve est justement l'une des clés du wear-levelling. Par contre, effectivement, si on effectue une passe d'écriture à zéro sur l'ensemble du SSD, il y a un nombre de cellule égale à la taille de l'espace de réserve qui ne sera pas affecté directement (elles le seront plus tard, lors du passage du garbage collector), mais ce n'est pas forcément les cellules qui étaient dans l'espace de réserve avant le lancement de la passe d'écriture à zéro.

Par contre, là où je suis repassé de presque 2mn de boot à 31 secondes c'est (certes en effaçant de nouveau) mais surtout en effectuant 16 partitions avant de reformater en une seule.

Physiquement comment cela s'explique-t'il selon vous?

Là j'en ai absolument aucune idée. C'est vraiment un comportement surprenant, et c'est la première fois que j'entends parler d'une procédure de ce genre.