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

[Kalm]

Merci steph_run

Ça confirme le rappel fait en première page au sujet des contrôleur Marvell

Ce message a été modifié par Kalm - 17 Nov 2010, 18:37.

[Fogi]

Je me suis amusé à faire un bench rapide du RamDisk que j'ai créé sur mon Mini ...

[attachment=36048:image_20...00.07.15.jpg]

[PierreH]

J'ai lu un article très intéressant sur le SSD et Mac OSX. Il en sort que le SSD du MacBook Air (génération précédente) ne perd pas en perf après un test en labo prolongé, mais comme le dit l'article, il est dur à l'heure du test de savoir si c'est grâce à OSX qui gère bien ses fichiers, ou si c'est parce que ce SSD est moins performant que d'autres et que donc les dégradations sont moins visibles...

[roinigo]

Hello à tous !
Voici ma contribution : VEXTEX 2 - 240 Go installé hier dans Mac pro de la signature.
Dessus : un clone de mon Macintosh HD (système + applis).
Qu'en pensez-vous ?
[attachment=36055:Capture_...14.39.14.jpg]

[Kalm]

Hello à tous !
Voici ma contribution : VEXTEX 2 - 240 Go installé hier dans Mac pro de la signature.
Dessus : un clone de mon Macintosh HD (système + applis).
Qu'en pensez-vous ?

Si tu veux une comparaison,tu postes avec QuickBench.Tu as d autre SSD en première page,entre autre des vertex2.

Ce message a été modifié par Kalm - 18 Nov 2010, 15:52.

[Kalm]

)

J'ai lu un article très intéressant sur le SSD et Mac OSX. Il en sort que le SSD du MacBook Air (génération précédente) ne perd pas en perf après un test en labo prolongé, mais comme le dit l'article, il est dur à l'heure du test de savoir si c'est grâce à OSX qui gère bien ses fichiers, ou si c'est parce que ce SSD est moins performant que d'autres et que donc les dégradations sont moins visibles...

Il est vieux mais pas encore idiot,tu le vois installer des SSD perdant 50% de leurs performances,il privilège la fiabilité a la performance brut.
En installant par exemple un contrôleur SandForce cela le pousserait a installer le TRIM,ce qui est a mon avis la dernière de ses préoccupation.Pour SJ celui qui veut un SSD ,il achète un Mac avec SSD(moins performant mais plus cher )la boucle est bouclé.
Et rien a faire si les autres SSD perdent leurs performances en absence de TRIM.

Ce message a été modifié par Kalm - 18 Nov 2010, 16:00.

[matcauthron]

Suite à un post ailleurs sur le forum, on m'a suggéré de poster ce petit test Xbench. C'est pour un SSD Vertex 2 120 Go, mais le modèle 3"1/2 connecté dans le Mac Pro de ma signature (et donc sans aucun adaptateur).

Je manque de recul pour savoir à quel point c'est satisfaisant, par contre.

[attachment=36067:xbench_vertex2_35.png]

Ce message a été modifié par matcauthron - 18 Nov 2010, 20:53.

[steph_run]

Salut les pommés,

Après avoir posté les benchs bruts de ma partoche système après 6 mois d’usage quotidien, je vous propose, en l’absence de TRIM, de voir l’intérêt (ou pas) d’une procédure de « reconditionnement » avec l’utilitaire Disktester de Diglloyd.

Contexte :

MacBook Pro I5 2,4Ghz – 4Go / OSX 10.6.5
SSD : Crucial C300 / 256 Go / Firmware Rev. 002 /Contrôleur Marvell
Mise en service Mai 2010. 6 mois d’utilisation intensive quotidienne.
3 partitions : OSX+Appli / Données / Win7.

J’ai choisi cette fois de tester la partition « Données ». C’est la partition HFS+ plus sollicitée en terme de lectures/écritures/effacements au quotidien, donc celle ou l’absence de TRIM devrait le plus se faire sentir. Cette partition de travail de 58 Go est à ce jour utilisée par 25,6 Go de données réparties en 12369 fichiers soit une taille moyenne de fichier d’environ 2 Mo.

Protocole :
1) Bench Série A (QuickBench . test standard / étendu / personnalisé sur 5 passes à chaque fois)
2) Sauvegarde de l’intégralité des données sur HD externe (TriBackup)
3) Effacement des données ET de l’espace libre avec écriture de 0 (Utilitaire disque OSX)
4) Bench Série B (mêmes tests)
5) Reconditionnement avec l’utilitaire Disktester de Diglloyd (Voir ici
6) Bench Série C (mêmes tests)
7) Restauration des Données

RRESULTATS.

SERIE A . AVANT RECONDITIONNEMENT


.

.

.

SERIE C. APRES RECONDITIONNEMENT


.

.

.

COMMENTAIRES

Quasiment aucune différence significative (+/- 1 Mb/s) sur les 3 tests entre la série A et B : Conclusion : la simple procédure « effacement du disque avec écriture de 0 » ne sert strictement à rien, du moins sur ce modèle de SSD. Pourtant cette procédure a largement été conseillée et débattue sur certains sites et forums. (je ne publie donc pas la série B pour ne pas alourdir le post)

Plus surprenant : Quasiment aucune différence non plus après la procédure de reconditionnement (12 itérations, tests toutes les 4 itérations) !!! Le chouia de Mb/s que l’on gagne d’un coté se perd de l’autre.

A ce stade on en vient à formuler 3 hypothèses (sans ordre de probabilité) :

1) Soit la commande RECONDITION de Diglloyd/Disktester est mal foutue ou ne prend pas convenablement en charge ce modèle de SSD/contrôleur.

2) Soit le Crucial C300/Marvell a une excellente tenue dans temps.

3) Soit OSX supplée l’absence de TRIM par d’autres mécanismes (lequels ?) qui évitent parfaitement la dégradation des performances. Cette hypothèse a déjà largement été formulée par ailleurs mais sans aucune explication technique crédible.

On pourrait alors penser que si Apple ne se presse pas pour implémenter le TRIM sous OS/X c’est qu’ils sont peut être parfaitement conscient de son inutilité en l’espèce. Dommage qu’ils ne communiquent pas non plus sur cet aspect technique.

Ce qu’il manque pour pouvoir affiner cette réflexion c’est une série de test lorsque le disque était neuf. Peut-être celui de Kierkegaard en début de post (même modèle SSD mais sur config différente) ? Auquel cas resteraient les hypothèses 2 ou 3 que l’on pourrait alors discriminer par le même protocole de test avec un autre modèle de SSD.

Voilà, après 2 heures de boulot je ne retire aucun bénéfice en terme de perf sur ce SSD (mais il n’y en avait clairement pas besoin). J’ai en revanche le sentiment d’avoir fait avancer la science.

Ce message a été modifié par steph_run - 19 Nov 2010, 09:44.

[Guest_anonym_d019ede3_*]

Aïe!

Voici les résultats obtenus sur mon SSD INTEL X 25 V 40Go acheté début juillet, non re-conditionné mais re-cloné il y a quelques jours:

Concernant la perte en utilisation, j'ai certes de faibles perfs avec mon SSD comparé à certains "monstres" ici, par contre là j'ai posté deux jours après avoir effacé en 7 passes, partitionné en 16 puis revenu en une et recloné et je suis revenu de 2mn de boot au bout de 4 mois à 31 secondes.

De préciser que ce n'est qu'une partie d'une manip de reconditionnement par l'utilitaire de disque dont je n'ai pas compris la fin (topic en anglais et je ne suis pas très fort, du coup je n'ai pas compris comment procéder pour la fin et la manip concernant l'image disque).

Lien pour le reconditionnement gratuit par l'utilitaire de disque:
http://jasontomczak.com/2010/06/21/recondi...e-mac-for-free/

J'avais déjà tenté le refo de mon SSD, effacé 1 passe zéros, et recloné mais sans changement de perfos, mais là j'ai bien senti la différence.

Edit: Ce qui est par contre dommage, c'est que je n'ai pas pensé à faire un test Bench avant l'opération pour pouvoir comparer les chiffres...

Ce message a été modifié par anonym_d019ede3 - 19 Nov 2010, 10:23.

[Kalm]

Quasiment aucune différence significative (+/- 1 Mb/s) sur les 3 tests

Plus surprenant : Quasiment aucune différence non plus après la procédure de reconditionnement (12 itérations, tests toutes les 4 itérations) !!! Le chouia de Mb/s que l’on gagne d’un coté se perd de l’autre.

Voilà, après 2 heures de boulot je ne retire aucun bénéfice en terme de perf sur ce SSD (mais il n’y en avait clairement pas besoin). J’ai en revanche le sentiment d’avoir fait avancer la science.

Salut.

Comme précisé en première page,

JMicron JMF618
Pas d’impact significatif en écriture aléatoire, les écritures séquentielles peuvent baisser de 10%.

Contrôleur Marvell
1)Les écritures aléatoires peuvent être divisées par 4, les écritures séquentielles peuvent baisser de 33%
Difficile les fin de semaines.

Dans un de ses post ,Panta avait fait le reconditionnement d un Verfex60GB ( contrôleur hyndilix)avec DiskTester.
te propose d aller jeter un œil
avant reconditionnement 39MB/s/130MB/s Ecriture /Lecture
Apres reconditionnement 130/140 Mo en écriture (240/250 en lecture).

http://forum.macbidouille.com/index.php?s=...t&p=3287727

Ce message a été modifié par Kalm - 22 Nov 2010, 07:43.

[Crazy Vessel]

Bonjour,

J'attends deux SSD commandés récemment, un OWC Mercury Extreme Pro de 120 Go, et un OCZ Vertex 2 de 240 Go.

Je posterai mes bench des deux SSD neufs, dès réception.

Le Mercury est un 2,5", il sera installé dans la 2e baie optique de mon Mac Pro 2010 6 core. Destiné au système + applis.
L'OCZ est un 3,5", installé dans une des 4 baies du mac. Destiné au dossier "maison" + données en cours de travail.

J'ai une question pour ceux qui ont commandé et reçu des OCZ neufs: Les avez-vous reçus en boîte ou non? Etaient-ils scellés, boîte scellée, SSD scellé ou les deux? (oui, j'ai des doutes sur le fait que mon Vertex soit 100% neuf, alors autant prévoir en cas de mauvaise surprise à la réception!)

Merci

[Kalm]

Le Mercury est un 2,5", il sera installé dans la 2e baie optique de mon Mac Pro 2010 6 core. Destiné au système + applis.
L'OCZ est un 3,5", installé dans une des 4 baies du mac. Destiné au dossier "maison" + données en cours de travail.

Salut

Quels critères a l exception du format(2.5/3.5)t ont amené a choisir l un plus que l autre pour y installer tes données.

Ce message a été modifié par Kalm - 19 Nov 2010, 13:51.

[Crazy Vessel]

Le Mercury est un 2,5", il sera installé dans la 2e baie optique de mon Mac Pro 2010 6 core. Destiné au système + applis.
L'OCZ est un 3,5", installé dans une des 4 baies du mac. Destiné au dossier "maison" + données en cours de travail.

Salut

Quels critères a l exception du format(2.5/3.5)t ont amené a choisir l un plus que l autre pour y installer tes données.

Question plus que pertinente!

En fait je me pose encore la question, dans la mesure où je crois savoir que le Mercury est plus stable dans le temps, et souffre beaucoup moins des séquences répétitives d'écriture/effacement/écriture, que le Vertex 2. Mais 120 Go c'est le bon format pour applis + système, et 240 Go pour les données de travail, ça me convient...

Mais...

Disons que mon achat s'est fait en deux temps:

1) j'ai commandé mon Mercury avant même de recevoir mon mac pro, il y a... 3 semaines (toujours pas reçu -USPS- je sais c'est TRES long). A cette époque, je pensais me contenter du HDD 2To commandé avec la machine chez Apple pour les données.

2)quand j'ai reçu le mac (ça fait 15 jours), je me suis aperçu que le DD hitachi de 2To me soûlait par ses grattements permanents (j'aime le silence!), et j'ai décidé de commander un 2e SSD, le Vertex 2 3,5" de 240 Go, pour y installer ce que j'utilise le plus souvent, bibliothèque iTunes et images/films en cours de travail.

Le choix du Vertex s'est fait à cause de la dispo en France, j'en ai marre d'attendre pour faire toutes mes install, j'ai besoin d'être opérationnel d'urgence!

Si j'avais eu plus de temps, je pense que j'aurais commandé les 2 SSD chez OWC (Mercury extreme pro)

Ce message a été modifié par Crazy Vessel - 19 Nov 2010, 14:26.

[matcauthron]

J'ai une question pour ceux qui ont commandé et reçu des OCZ neufs: Les avez-vous reçus en boîte ou non? Etaient-ils scellés, boîte scellée, SSD scellé ou les deux? (oui, j'ai des doutes sur le fait que mon Vertex soit 100% neuf, alors autant prévoir en cas de mauvaise surprise à la réception!)

Oui, il était dans une belle boîte noire et épaisse, à l'intérieur rembourré. La boîte était bien enveloppée dans un plastique qui ne portait pas de marque d'ouverture, et le disque lui-même était dans son plastique anti-statique scellé.

[Crazy Vessel]

J'ai une question pour ceux qui ont commandé et reçu des OCZ neufs: Les avez-vous reçus en boîte ou non? Etaient-ils scellés, boîte scellée, SSD scellé ou les deux? (oui, j'ai des doutes sur le fait que mon Vertex soit 100% neuf, alors autant prévoir en cas de mauvaise surprise à la réception!)

Oui, il était dans une belle boîte noire et épaisse, à l'intérieur rembourré. La boîte était bien enveloppée dans un plastique qui ne portait pas de marque d'ouverture, et le disque lui-même était dans son plastique anti-statique scellé.

Merci!

[Kalm]

Le Mercury est un 2,5", il sera installé dans la 2e baie optique de mon Mac Pro 2010 6 core. Destiné au système + applis.
L'OCZ est un 3,5", installé dans une des 4 baies du mac. Destiné au dossier "maison" + données en cours de travail.

Salut

Quels critères a l exception du format(2.5/3.5)t ont amené a choisir l un plus que l autre pour y installer tes données.

En fait je me pose encore la question, dans la mesure où je crois savoir que le Mercury est plus stable dans le temps, et souffre beaucoup moins des séquences répétitives d'écriture/effacement/écriture, que le Vertex 2.

En faite c est l inverse ,une fois les Applications installées,tu n auras que peu d écriture sur le volume system (Mercury)mais beaucoup plus sur la manipulation de tes données(Vertex2)
Ex:Premier lancement de PS,40Mo/s en lecture pour un pic 120ko/s en écriture,
pour l expérience ,juste avec un copier/coller d un AVI HDD>SSD (1.5Go )suis arrivé 70Mo/s en écriture.

Ce message a été modifié par Kalm - 19 Nov 2010, 15:18.

[Crazy Vessel]

Le Mercury est un 2,5", il sera installé dans la 2e baie optique de mon Mac Pro 2010 6 core. Destiné au système + applis.
L'OCZ est un 3,5", installé dans une des 4 baies du mac. Destiné au dossier "maison" + données en cours de travail.

Salut

Quels critères a l exception du format(2.5/3.5)t ont amené a choisir l un plus que l autre pour y installer tes données.

En fait je me pose encore la question, dans la mesure où je crois savoir que le Mercury est plus stable dans le temps, et souffre beaucoup moins des séquences répétitives d'écriture/effacement/écriture, que le Vertex 2.

En faite c est l inverse ,une fois les Applications installées,tu n auras que peu d écriture sur le volume system mais beaucoup plus sur la manipulation de tes données.
Ex:Premier lancement de PS,40Mo/s en lecture pour un pic 120ko/s en écriture,
pour l expérience ,juste avec un copier/coller d un AVI HDD>SSD (1.5Go )suis arrivee 70Mo/s en écriture.

As-tu lu le reste de mon post?

Vertex=240Go, Mercury=120Go

Je dis justement que j'aurais préféré plus de Mercury et moins de Vertex. Mais il se pose le problème de la capacité de chaque disque.

Quoi que je fasse, la partie la plus "immobile" de mes données n'occupera que 60 Go, pas plus. Les limitations du Vertex seront donc forcément mises à l'épreuve, et j'aurai probablement besoin, quel que soit mon choix de disposition des données, de vérifier l'état du SSD, et de le "régénérer" de temps en temps si nécessaire.

Vertex: capacité 240 Go, je ne peux pas l'utiliser "que" pour le système, trop de gâchis. Donc il y aura du mouvement de données sur le disque. Donc je devrais de toutes façons le surveiller. Donc peu importe où je mets le système.

En gros, dans mon cas:
Système + applis = 60 Go environ
Maison: 1)Musique = 40 Go (je ne veux rien scinder)
2)Image = + de 100 Go (que je scinderai en 2, partie utile au traitement et stockage)
3)Sequences = + de 300 Go (que je scinderai en 2, partie utile au traitement et stockage)

Pour scinder les données, j'avoue que je ne l'ai pas encore fait, je verrai ça en fonction des applis que j'utilise.

Je pense mettre Système+applis sur le Mercury, et Maison "dégraissée" sur le Vertex

Mais bon, je n'ai pas pensé à tout, et si quelqu'un a des idées pour un meilleur agencement de mes SSD (avec partition par ex, mais pas sûr que ce soit recommandé pour un SSD), je lirai cela avec intérêt.

Ce message a été modifié par Crazy Vessel - 19 Nov 2010, 16:02.

[Kalm]

En fait je me pose encore la question, dans la mesure où je crois savoir que le Mercury est plus stable dans le temps, et souffre beaucoup moins des séquences répétitives d'écriture/effacement/écriture, que le Vertex 2.

Mea culpa,j ai interprété cette phrase comme un choix plus judicieux pour ton system.

Ce message a été modifié par Kalm - 19 Nov 2010, 16:17.

[Kalm]

Mais bon, je n'ai pas pensé à tout, et si quelqu'un a des idées pour un meilleur agencement de mes SSD (avec partition par ex, mais pas sûr que ce soit recommandé pour un SSD), je lirai cela avec intérêt.

Partitionner son SSD peut avoir un intérêt pour organiser son espace travail et faciliter le clonage,
mais dans l espoir de gagner en performance cela n aura aucun intérêt car les temps d accès sont constants car si j ai bien compris , nous n avons aucune maitrise sur la répartition physique des données.

[steph_run]

Partitionner son SSD peut avoir un intérêt pour organiser son espace travail et faciliter le clonage,
mais dans l espoir de gagner en performance cela n aura aucun intérêt car les temps d accès sont constants car si j ai bien compris , nous n avons aucune maitrise sur la répartition physique des données.

Tu sous entend que les partitions ne seraient pas des blocs contigus ?
Je me suis posé cette question par rapport à "l'inefficacité" du reconditionnement : Et si cela était du aux partitions ?

[Kalm]

Tu sous entend que les partitions ne seraient pas des blocs contigus ?

Bonne question

Serais bien incapable de te répondre,
il faut bien avouer qu'il n'y a pas de vrai documentation ou article claire mais cela semble le plus logique,
d autre personnes bien plus qualifiées seront peut être en mesure de nous éclairer sur le sujet.
En ce qui concerne l accès au disque ,aucun doute le temps accès n en serra pas réduit puisque il est le même sur tt le SSD

Ce message a été modifié par Kalm - 21 Nov 2010, 12:23.

[Kierkegaard]

Si je n'ai rien loupé, il n'existe encore aucun moyen de redonner un coup de jeunesse à un SSD, via un logiciel, sous Mac OS X. Par conséquent, impossible de rendre complètement vierges les cellules d'un SSD sauf avec Secure Erase sous Windows 7, si j'ai bien compris. Ce qui est assez cocasse dans tout cela, c'est que Windows 7 a la fonction TRIM et Secure Erase alors que Mac OS X, qui souffre de l'absence du TRIM, devrait au moins nous offrir l'équivalent de Secure Erase en attendant d'intégrer le TRIM.

Ce message a été modifié par Kierkegaard - 20 Nov 2010, 19:04.

[Kalm]

Si je n'ai rien loupé, il n'existe encore aucun moyen de redonner un coup de jeunesse à un SSD, via un logiciel, sous Mac OS X. Par conséquent, impossible de rendre complètement vierges les cellules d'un SSD sauf avec Secure Erase sous Windows 7, si j'ai bien compris. Ce qui est assez cocasse dans tout cela, c'est que Windows 7 a la fonction TRIM et Secure Erase alors que Mac OS X, qui souffre de l'absence du TRIM, devrait au moins nous offrir l'équivalent de Secure Erase en attendant d'intégrer le TRIM.

Salut Kierkegaard'

Bon un peu fatigué,puisque je rentre de virée .mais j espere que tu as bien compris que les contrôleurs étaient bien diffèrent les uns des autres et qu en autre le contrôleurs Marvell était moins propice a cette fragmentation ,je ne parle pas de l usure.
En ce qui concerne le reconditionnement ,de toute evidence ,il sera a AMA plus efficace sur les contrôleur gérant moins bien cette fragmentation..

Ce message a été modifié par Kalm - 20 Nov 2010, 21:33.

[SartMatt]

Partitionner son SSD peut avoir un intérêt pour organiser son espace travail et faciliter le clonage,
mais dans l espoir de gagner en performance cela n aura aucun intérêt car les temps d accès sont constants car si j ai bien compris , nous n avons aucune maitrise sur la répartition physique des données.

Tu sous entend que les partitions ne seraient pas des blocs contigus ?
Je me suis posé cette question par rapport à "l'inefficacité" du reconditionnement : Et si cela était du aux partitions ?

Je confirme. Sur un disque dur, les adresses logiques sont mappées statiquement sur des adresse physiques, de l'extérieur du disque vers l'intérieur du disque, sauf dans le cas particuliers des secteurs réalloués (les disques durs contiennent un peu plus de secteurs que leur capacité nominale, ce qui permet de remapper les secteurs défectueux vers un de ces secteurs supplémentaires).
Deux adresses logiques consécutives correspondent donc à deux adresse physiques consécutives.
Et donc, une partition, qui est un bloc contigu d'adresses logiques et un bloc contigu d'adresses physiques.

Sur un SSD avec wear-levelling (donc les SSD SATA en vente actuellement, les clés USB haut de gamme et les cartes mémoire haut de gamme), le lien entre adresse logique et adresse physique est totalement dynamique. Non seulement il n'y a plus la moindre garantie de contiguité, mais en plus, une même adresse logique peut correspondre à différentes adresses physiques, au fil des écritures.

Du coup, comme dit Kalm, faire des partitions sur un SSD n'a aucun impact sur les performances ou sur l'usure, le seul intérêt que ça a, c'est pour l'organisation. Par exemple, ça peut être intéressant de séparer systèmes et applications/données sur deux partitions différentes, pour ne pas effacer les applications et les données lors d'une clean install du système.

Ce qui est assez cocasse dans tout cela, c'est que Windows 7 a la fonction TRIM et Secure Erase alors que Mac OS X, qui souffre de l'absence du TRIM, devrait au moins nous offrir l'équivalent de Secure Erase en attendant d'intégrer le TRIM.

Non, Windows 7 n'a que le TRIM.
À ma connaissance, aucun système d'exploitation ne propose nativement la fonction Secure Erase : d'abord, parce que les systèmes d'exploitations sont faits pour ne pas pouvoir se faire hara-kiri, ensuite parce que de toute façon, les BIOS empêchent l'envoie de la commande Secure Erase vers les disques qui sont présents au moment du boot.

Pour faire un Secure Erase sur un PC sous Windows ou Linux, il faut généralement passer par un utilitaire dédié (le plus populaire est HDDErase), qu'on utilise en bootant sur un CD ou une clé USB (perso, j'utilise Ultimate Boot CD, qui inclus HDDErase).

Le problème, c'est que ces outils son très pointilleux sur les paramétrages du BIOS (il faut que le contrôleur SATA soit en mode émulation USB et que le SSD ait été branché après le boot, pour que la sécurité ne soit pas activée), et qu'ils ne sont malheureusement pas compatibles avec l'émulation BIOS de Bootcamp (sur mon MBP, j'arrive à démarrer l'Ultimate Boot CD, j'arrive à lancer HDDErase, mais il fige sur la détection des disques, exactement comme sur mes PC en configuration par défaut, avec l'AHCI activé).


Ce message a été modifié par SartMatt - 20 Nov 2010, 20:17.

[Kierkegaard]

Si je n'ai rien loupé, il n'existe encore aucun moyen de redonner un coup de jeunesse à un SSD, via un logiciel, sous Mac OS X. Par conséquent, impossible de rendre complètement vierges les cellules d'un SSD sauf avec Secure Erase sous Windows 7, si j'ai bien compris. Ce qui est assez cocasse dans tout cela, c'est que Windows 7 a la fonction TRIM et Secure Erase alors que Mac OS X, qui souffre de l'absence du TRIM, devrait au moins nous offrir l'équivalent de Secure Erase en attendant d'intégrer le TRIM.

Salut Kierkegaard'

Bon un peu fatigué,puisque je rentre de virée .mais j espere que tu as bien compris que les contrôleurs étaient bien diffèrent les uns des autres et qu en autre le contrôleurs Marvell était moins propice a cette fragmentation ,je ne parle pas de l usure.
En ce concerne le reconditionnement ,de toute evidence ,il sera a AMA plus efficace sur les contrôleur gérant moins bien cette fragmentation..

Merci.

Et si on efface son SSD et qu'on réinstalle tout le système Mac OS X, est-ce qu'il y a un risque de dégradation des performances après un tel effacement / réécriture?

Partitionner son SSD peut avoir un intérêt pour organiser son espace travail et faciliter le clonage,
mais dans l espoir de gagner en performance cela n aura aucun intérêt car les temps d accès sont constants car si j ai bien compris , nous n avons aucune maitrise sur la répartition physique des données.

Tu sous entend que les partitions ne seraient pas des blocs contigus ?
Je me suis posé cette question par rapport à "l'inefficacité" du reconditionnement : Et si cela était du aux partitions ?

Je confirme. Sur un disque dur, les adresses logiques sont mappées statiquement sur des adresse physiques, de l'extérieur du disque vers l'intérieur du disque, sauf dans le cas particuliers des secteurs réalloués (les disques durs contiennent un peu plus de secteurs que leur capacité nominale, ce qui permet de remapper les secteurs défectueux vers un de ces secteurs supplémentaires).
Deux adresses logiques consécutives correspondent donc à deux adresse physiques consécutives.
Et donc, une partition, qui est un bloc contigu d'adresses logiques et un bloc contigu d'adresses physiques.

Sur un SSD avec wear-levelling (donc les SSD SATA en vente actuellement, les clés USB haut de gamme et les cartes mémoire haut de gamme), le lien entre adresse logique et adresse physique est totalement dynamique. Non seulement il n'y a plus la moindre garantie de contiguité, mais en plus, une même adresse logique peut correspondre à différentes adresses physiques, au fil des écritures.

Du coup, comme dit Kalm, faire des partitions sur un SSD n'a aucun impact sur les performances ou sur l'usure, le seul intérêt que ça a, c'est pour l'organisation. Par exemple, ça peut être intéressant de séparer systèmes et applications/données sur deux partitions différentes, pour ne pas effacer les applications et les données lors d'une clean install du système.

Ce qui est assez cocasse dans tout cela, c'est que Windows 7 a la fonction TRIM et Secure Erase alors que Mac OS X, qui souffre de l'absence du TRIM, devrait au moins nous offrir l'équivalent de Secure Erase en attendant d'intégrer le TRIM.

Non, Windows 7 n'a que le TRIM.
À ma connaissance, aucun système d'exploitation ne propose nativement la fonction Secure Erase : d'abord, parce que les systèmes d'exploitations sont faits pour ne pas pouvoir se faire hara-kiri, ensuite parce que de toute façon, les BIOS empêchent l'envoie de la commande Secure Erase vers les disques qui sont présents au moment du boot.

Pour faire un Secure Erase sur un PC sous Windows ou Linux, il faut généralement passer par un utilitaire dédié (le plus populaire est HDDErase), qu'on utilise en bootant sur un CD ou une clé USB (perso, j'utilise Ultimate Boot CD, qui inclus HDDErase).

Le problème, c'est que ces outils son très pointilleux sur les paramétrages du BIOS (il faut que le contrôleur SATA soit en mode émulation USB et que le SSD ait été branché après le boot, pour que la sécurité ne soit pas activée), et qu'ils ne sont malheureusement pas compatibles avec l'émulation BIOS de Bootcamp (sur mon MBP, j'arrive à démarrer l'Ultimate Boot CD, j'arrive à lancer HDDErase, mais il ne voit pas mon SSD, exactement comme sur mon PC en configuration par défaut, avec l'AHCI activé).

Merci Matt.

J'ai bien rigolé en lisant: ... « parce que les systèmes d'exploitations sont faits pour ne pas pouvoir se faire hara-kiri... »

[Kalm]

Merci SartMatt, parce que la. je commencais a patauger.
Kierkegaard ,si tu peux attendre demain, pour te répondre car la , suis l emprise d une soirée bien arrosée a Saigon.

Ce message a été modifié par Kalm - 20 Nov 2010, 20:43.

[Kierkegaard]

Supprimer.

Ce message a été modifié par Kierkegaard - 13 Dec 2010, 01:53.

[Kalm]

mais en plus, une même adresse logique peut correspondre à différentes adresses physiques, au fil des écritures.

C est quand même un sacrés bordel ces SSD

Ce message a été modifié par Kalm - 20 Nov 2010, 21:53.

[Kierkegaard]

Un petit rappel au sujet des contrôleurs

Source:hardware.fr

Comme nous l’avons déjà expliqué à plusieurs reprises, notamment ici, la commande TRIM est importante puisqu’elle permet d’éviter une dégradation des performances du SSD au fur et à mesure de son utilisation.

Bien entendu, l’impact sur les performances varie d’un contrôleur à l’autre. En effectuant des écritures séquentielles sur un SSD sur lequel nous avons auparavant effectué des écritures aléatoires, et vice-versa, voici nos conclusions quand à la sensibilité des contrôleurs vis-à-vis de la fragmentation :

- Indilinx Barefoot :
Les écritures aléatoires peuvent être divisées par 4.5, les écritures séquentielles par 5
- Intel PC29AS21BA0 :
Les écritures aléatoires peuvent être divisées 4, pas d’impact significatif en écriture séquentielle
- JMicron JMF618 :
Pas d’impact significatif en écriture aléatoire, les écritures séquentielles peuvent baisser de 10%
- Marvell 88SS9174 :
Les écritures aléatoires peuvent être divisées par 4, les écritures séquentielles peuvent baisser de 33%

Quasiment aucune différence significative (+/- 1 Mb/s) sur les 3 tests

Plus surprenant : Quasiment aucune différence non plus après la procédure de reconditionnement (12 itérations, tests toutes les 4 itérations) !!! Le chouia de Mb/s que l’on gagne d’un coté se perd de l’autre.

Voilà, après 2 heures de boulot je ne retire aucun bénéfice en terme de perf sur ce SSD (mais il n’y en avait clairement pas besoin). J’ai en revanche le sentiment d’avoir fait avancer la science.

Salut.

Comme précisé en première page,

Contrôleur Marvell
Pas d’impact significatif en écriture aléatoire, les écritures séquentielles peuvent baisser de 10%.
Donc AMHA ,tu peux difficilement faire beaucoup mieux,même en faisant une SecurErase.

Pour le contrôleur Marvell, lequel des deux énoncés suivants est vrai, celui du premier post ou celui du second?

Marvell 88SS9174 :

A ) Les écritures aléatoires peuvent être divisées par 4, les écritures séquentielles peuvent baisser de 33%

Contrôleur Marvell

B ) Pas d’impact significatif en écriture aléatoire, les écritures séquentielles peuvent baisser de 10%.

[SartMatt]

Un petit rappel au sujet des contrôleurs

Source:hardware.fr

Comme nous l’avons déjà expliqué à plusieurs reprises, notamment ici, la commande TRIM est importante puisqu’elle permet d’éviter une dégradation des performances du SSD au fur et à mesure de son utilisation.

Bien entendu, l’impact sur les performances varie d’un contrôleur à l’autre. En effectuant des écritures séquentielles sur un SSD sur lequel nous avons auparavant effectué des écritures aléatoires, et vice-versa, voici nos conclusions quand à la sensibilité des contrôleurs vis-à-vis de la fragmentation :

- Indilinx Barefoot :
Les écritures aléatoires peuvent être divisées par 4.5, les écritures séquentielles par 5
- Intel PC29AS21BA0 :
Les écritures aléatoires peuvent être divisées 4, pas d’impact significatif en écriture séquentielle
- JMicron JMF618 :
Pas d’impact significatif en écriture aléatoire, les écritures séquentielles peuvent baisser de 10%
- Marvell 88SS9174 :
Les écritures aléatoires peuvent être divisées par 4, les écritures séquentielles peuvent baisser de 33%

Quasiment aucune différence significative (+/- 1 Mb/s) sur les 3 tests

Plus surprenant : Quasiment aucune différence non plus après la procédure de reconditionnement (12 itérations, tests toutes les 4 itérations) !!! Le chouia de Mb/s que l’on gagne d’un coté se perd de l’autre.

Voilà, après 2 heures de boulot je ne retire aucun bénéfice en terme de perf sur ce SSD (mais il n’y en avait clairement pas besoin). J’ai en revanche le sentiment d’avoir fait avancer la science.

Salut.

Comme précisé en première page,

Contrôleur Marvell
Pas d’impact significatif en écriture aléatoire, les écritures séquentielles peuvent baisser de 10%.
Donc AMHA ,tu peux difficilement faire beaucoup mieux,même en faisant une SecurErase.

Pour le contrôleur Marvell, lequel des deux énoncés suivants est vrai, celui du premier post ou celui du second?

Marvell 88SS9174 :

A ) Les écritures aléatoires peuvent être divisées par 4, les écritures séquentielles peuvent baisser de 33%

Contrôleur Marvell

B ) Pas d’impact significatif en écriture aléatoire, les écritures séquentielles peuvent baisser de 10%.

Celui du premier.
Cf la source : http://www.hardware.fr/articles/794-7/comp...s-compares.html