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.

[Kierkegaard]

Voici 3 captures d'écran effectuées sur un Crucial C300 256Go, via l'application QuickBench:

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

[Kalm]

Gros UP

Cette initiative n a pas pour but de connaitre celui qui a la plus …..mais a titre d information pour pouvoir au mieux diriger les futures acheteurs de SSD.Donc n hésitez pas, lâchez vous. faites vomir vos Bench

[Kalm]

Quickbench Vertex2 250GB

[Kierkegaard]

QuickBench: Crucial C300 256Go

Si on veut faire maintenant dans le « Graphic View » plutôt que dans le « Numeric View », voici alors une nouvelle série de captures d'écran:

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

[Kalm]

QuickBench: Crucial C300 256Go

Si on veut faire maintenant dans le « Graphic View » plutôt que dans le « Numeric View », voici alors une nouvelle série de captures d'écran:

@Kierkegaard,n est pas eu vraiment le choix ,ce Vertex2 ne m appartient pas

[Kierkegaard]

QuickBench: Crucial C300 256Go

Si on veut faire maintenant dans le « Graphic View » plutôt que dans le « Numeric View », voici alors une nouvelle série de captures d'écran:

@Kierkegaard,n est pas eu vraiment le choix ,ce Vertex2 ne m appartient pas

Aucun problème.

[Guest_anonym_d019ede3_*]

Bonne initiative,
Bon pour ma part je ne poste pas c'est le bo*d*l sur mon SSD Intel X25V 40Go et en plus c'est loin d'être une bête de course, puis suis pas sûr de ne pas avoir un test faussé par ma carte mère qui flanche vu ma lenteur de boot 2mn...

Par contre faudra penser aussi à relancer le post en début d'année vu qu'on attend pas mal de nouveautés en la matière...

[Kalm]

Graphic View A DATA S599 128 Sandforce.

[Kierkegaard]

Bonne initiative,
Bon pour ma part je ne poste pas c'est le bo*d*l sur mon SSD Intel X25V 40Go et en plus c'est loin d'être une bête de course, puis suis pas sûr de ne pas avoir un test faussé par ma carte mère qui flanche vu ma lenteur de boot 2mn...

Par contre faudra penser aussi à relancer le post en début d'année vu qu'on attend pas mal de nouveautés en la matière...

Tout à fait, c'est une excellente idée.

[Kalm]

Après examen du bench du Vetex 2 ,je soupçonne qu'il ait été testé avec leurs premier FW.

[Kierkegaard]

Après examen du bench du Vetex 2 ,je soupçonne qu'il ait été testé avec leurs premier FW.

Ça ne m'étonnerait pas du tout puisque sa vitesse en lecture / écriture est très loin d'atteindre les spécifications du fabricant.

[Pixelux]

OWC Mercury Extreme Pro 240 Go

[Kalm]

OWC Mercury Extreme Pro 240 Go

Merci

Excellente les performances de ce OWC

[Kalm]

Voici l Xbench d un Vertex 2 90Go fraîchement installé dans un Mac mini (trouvé
sur le forum MB) http://forum.macbidouille.com/index.php?sh...t&p=3337593



A gauche ADATA 599S a droite Vertex2

Ce message a été modifié par Kalm - 3 Dec 2010, 11:39.

[Kalm]

QuickBench:Vertex2 90GB

[radioman]

Petit rappel comparatif avec ceux -comme moi- qui ont encore des "bottes de plomb" en 7200 tr/mn
de gauche à droite: interne / FW800 / FW 400 les trois en 7200 tr/mn

[Kalm]

Bon rappel,on s habitue trop vite aux debits de ces SSD.

Ce message a été modifié par Kalm - 10 Nov 2010, 15:04.

[Kierkegaard]

Disk Test via l'application Xbench 1.3

Crucial C300 256Go

Ce message a été modifié par Kierkegaard - 10 Nov 2010, 18:39.

[Daystrom]

Super initiative.
çà donne une bonne idée de ce que l'on peut espérer.
Je commande pour la semaine prochaine 3 Vertex 2 de 240Go, que je mettrai pense mettre en raid 0 dans le Mac Pro de ma signature.
Théoriquement je devrais obtenir des débits quasiment 3 fois plus importants.

Ce message a été modifié par Daystrom - 11 Nov 2010, 05:47.

[PierreH]

Excellent idée ! QuickBench, ça marche sur Snow Leopard ou faut il installer Rosetta ? Ce dont je n'ai pas trop envie...

[Kalm]

Excellent idée ! QuickBench, ça marche sur Snow Leopard ou faut il installer Rosetta ? Ce dont je n'ai pas trop envie...

Ca marche.

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

[PierreH]

Tu veux dire ça marche directement ou ça marche dans Rosetta ?

[Kalm]

Tu veux dire ça marche directement ou ça marche dans Rosetta ?

j ai viré tte l architecture power pc sous ma machine ainsi que sur Quickbench,donc pas besoin de rosetta pr cette App

PS: Rosetta n est pas installé sur mon Mac.

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

[PierreH]

Merci pour toutes les infos, finalement j'ai récupéré le QuickBench de mon "vieux" MacBook sous Leopard, transféré dans les machines sous Snow et zoupla, voici les résultats - effectivement, sans l'aide de Rosetta.

Commençons par le MacBook Pro et son OCZ Vertex II, modèle 180Go (deux partitions, dont une de 120Go) :


Et ensuite, le MacBook Air 11" et son SSD de 64Go (qui fait 60Go d'ailleurs…)


Et bien même s'il n'est pas aussi véloce que le Vertex qui est quand même un monstre, il n'a pas à rougir ce petit MacBook Air !

[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:

[Fogi]

Voici l Xbench d un Vertex 2 90Go fraîchement installé dans un Mac mini (trouvé
sur le forum MB) http://forum.macbidouille.com/index.php?sh...t&p=3337593

Je poste ici de nouveaux benchs après quelques jours d'utilisation :

[attachment=36008:image_20...17.15.01.jpg][attachment=36009:image_20...17.06.49.
jpg][attachment=36010:image_20...17.07.35.jpg][attachment=36011:image_20...17.08
.
03.jpg]

Ce message a été modifié par Fogi - 15 Nov 2010, 17:21.

[Kalm]

Merci Fog,

Idée intéressante de reposter nos Bench après une période d utilisation,mais je pense qu il faudrait une période plus longue pour constater une dégradation de performances,3 mois en usage journalier me paraisse crédible.donc a suivre

[Kalm]

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%
- Samsung S3C29RBB01 :
Les écritures aléatoires peuvent être divisées par 14, les écritures séquentielles par 2.5
- SandForce SF-1200 :
Les écritures aléatoires peuvent être divisées par 2, les écritures séquentielles par 4
- Sandisk SDC4 :
Pas d’impact significatif en écriture aléatoire, les écritures séquentielles peuvent baisser de 25%
- Toshiba T6UG1XBG :
Pas d’impact significatif

Les contrôleurs Toshiba et JMicron JMF618 sont ceux qui souffrent le moins de la fragmentation, ceci étant probablement lié au fait que leurs performances en écriture aléatoire sont faibles ce qui laissent penser qu’ils ne font que peu d’usage du write combining. Le Sandisk G3 se comporte également assez bien. Les SSD Intel voient seulement leurs performances en écritures aléatoires impactées, mais ces dernières sont de bases assez élevées. Le Marvell est un peu impacté côté séquentiel mais surtout côté aléatoire, mais là encore les chiffres sont de bases élevés. Les contrôleurs les plus touchés sont l’Indilinx Barefoot, le SandForce SF-1200, et le Samsung S3C29RBB01, ce dernier étant très affecté du côté des écritures aléatoires.

Parmi ceux impactés en écriture séquentielles, certains contrôleurs arrivent à se remettre complètement de leur fragmentation lié à des accès aléatoire après une première écriture séquentielle. C’est notamment le cas chez Marvell, JMicron et Samsung. On constate des gains chez Indilinx et SandForce mais ils ne sont que partiels. D'autres mécanismes tels que le Garbage Collector tentent de profiter des phases de repos du SSD afin de défragmenter le SSD, mais ce type de mécanisme entraine des gains aléatoires, voir parfois inexistants malgré leur présence annoncée.

Seul le TRIM permet de maintenir le niveau initial de performances, que ce soit en accès séquentiels et surtout aléatoires. Pour rappel, pour bénéficier du TRIM, il faut une combinaison de 3 éléments gérant cette commande :

- Le système d’exploitation (Windows 7, Linux, bientôt Mac OS X) On l attend
- Les pilotes du contrôleur IDE/AHCI (sous W7, les pilotes Microsoft ou Intel)
- Le SSD

Ce message a été modifié par Kalm - 12 Dec 2010, 14:48.

[steph_run]

Quick Bench 4
MackBook Pro I5 2.4 / OSX 10.6.5

SSD Crucial C300 / 256 Go / firmware 002
Mise en service : Mai 2010 - Utilisation intensive au quotidien - Aucune maintenance encore effectuée (erase, recondition...)

3 partitions ( OSX / Données / Win7) . Partition testée "OSX" mais la partition ""données" procure des résultats quasi équivalents (un chouia plus faible sur écritures de petites taiilles)








Ce message a été modifié par steph_run - 17 Nov 2010, 16:07.

[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

[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%.

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

Merci Dr. ès SSD.

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

Merci à @Kalm pour son aide.

Voici de nouveau mes résultats après un re conditionnement à l'aide de disk tester:


Edit: toujours 31 sec au Boot.

Ce message a été modifié par anonym_d019ede3 - 23 Nov 2010, 14:40.

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

[Guest_anonym_d019ede3_*]

Question à SartMatt ou Crazy Vessel sur l'effacement rapport à cette manip:

http://jasontomczak.com/2010/06/21/recondi...e-mac-for-free/

Dans mon cas j'avais déjà tenté l'effacement et re clonage pour mon SSD sans résultats de gain au boot, d'ailleurs il précise que son effacement n'est peut-être pas une manip indispensable, après coup.

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?

Ce message a été modifié par anonym_d019ede3 - 24 Nov 2010, 11:26.

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

[TitouDoc]

Voici les benchs d'un C300 après 6 mois d'utilisation, no swipe, no reinstall en fait rien fait du tout a par l'utiliser

Ps : firmware 006.

Fichier(s) joint(s)

 1.tiff ( 207.32 Ko ) Nombre de téléchargements : 62
 2.tiff ( 180.59 Ko ) Nombre de téléchargements : 42
 3.tiff ( 180.65 Ko ) Nombre de téléchargements : 33

 

[Kierkegaard]

Voici les benchs d'un C300 après 6 mois d'utilisation, no swipe, no reinstall en fait rien fait du tout a par l'utiliser

Ps : firmware 006.

As-tu remarqué une différence sur ton Crucial C300 256Go depuis que tu as fait la mise à jour du firmware 0006? Est-ce mieux ou sensiblement pareil?

Merci.

[Kierkegaard]

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.

Quand j'ai commencé à faire des tests avec mon Crucial C300 256Go, via l'application QuickBench, il avait déjà 3 mois d'utilisation journalière. Cela dit, qui sait, il n'était peut-être pas plus rapide quand il était neuf.

[Guest_anonym_d019ede3_*]

Quand j'ai commencé à faire des tests avec mon Crucial C300 256Go, via l'application QuickBench, il avait déjà 3 mois d'utilisation journalière. Cela dit, qui sait, il n'était peut-être pas plus rapide quand il était neuf.

As-tu refais ta remise à plat de SSD avec les deux méthodes? celle du site jason que j'ai lu t'avais intéressé + suivi de disk tester?

Pour ma part j'ai réellement senti la différence surtout au boot, par contre je ne m'explique toujours pas ce qui à l'époque avait ralenti mon SSD à ce point en 3 jours seulement...

Là je reste stable depuis mes opérations de re condition et ça fait une semaine.

[Kierkegaard]

Quand j'ai commencé à faire des tests avec mon Crucial C300 256Go, via l'application QuickBench, il avait déjà 3 mois d'utilisation journalière. Cela dit, qui sait, il n'était peut-être pas plus rapide quand il était neuf.

As-tu refais ta remise à plat de SSD avec les deux méthodes? celle du site jason que j'ai lu t'avais intéressé + suivi de disk tester?

Pour ma part j'ai réellement senti la différence surtout au boot, par contre je ne m'explique toujours pas ce qui à l'époque avait ralenti mon SSD à ce point en 3 jours seulement...

Là je reste stable depuis mes opérations de re condition et ça fait une semaine.

J'ai essayé la méthode DiskTester Recondition SSD et je n'ai pas noté de changement qui soit réellement significatif. Quant à la méthode de jason, à quoi bon l'essayée puisque tu l'as testée et tu as obtenu un bien meilleur score avec celle de DiskTester?



Ce message a été modifié par Kierkegaard - 28 Nov 2010, 15:20.

[Guest_anonym_d019ede3_*]

Il est vrai que j'ai eu un meilleur score après Disk tester trois jour après avoir appliqué l'autre méthode, maintenant ce qui m'a fait obtenir une différence flagrante c'est bien le fait d'effacer 7 passes zéro suivi de 16 partitions pour revenir à une seule avant de re cloner.

Là où je n'ai peut être pas obtenu le résultat le plus impeccable c'est que je me suis arrêté à l'étape de l'image disque. Peut-être là ou Disk tester à terminé de faire du ménage.

J'ai envie de dire que ça se teste...

[Daystrom]

Voilà mes Vertex 2 sont enfin arrivé, ainsi que les disques dur pour mon NAS.
Je vous tiens au courant dans quelques jours le temps de sauvegarder tous cela.
Pour info j'ai choisis des Vertex en 3,5" pour la simplicité de la mise en place dans mon Mac Pro.

Click for large view - Uploaded with Skitch

[Kierkegaard]

Well, well, well, t'es vraiment full equip en HDD et en SSD. Ça va rouler tempête.

Ce message a été modifié par Kierkegaard - 1 Dec 2010, 20:12.

[stephn666]

Bonjour,
J'ai commander un Vertex 2 pour mon Mac mini 1.1 (donc sata 1) ce Dimanche (toujours pas reçu snifff) je vous vois beaucoup parler des débit "monstrueux", sachant parfaitement que ce dernier sera bridé, vous croyez qu'en utilisation "classique" je verrais la différence si j'avais du sata 2?

Ce message a été modifié par stephn666 - 2 Dec 2010, 13:09.

[Kalm]

Bonjour,
J'ai commander un Vertex 2 pour mon Mac mini 1.1 (donc sata 1) ce Dimanche (toujours pas reçu snifff) je vous vois beaucoup parler des débit "monstrueux", sachant parfaitement que ce dernier sera bridé, vous croyez qu'en utilisation "classique" je verrais la différence si j'avais du sata 2?

En réactivité, aucune puisque le sata 1 ne bride pas le temps d accès a ton SSD,en ce qui concerne les débits de transfère tu seras bridé a 150Mo/s au lieu des 270 théorique du Vertex2, mais si tu considères que sur un Sanforce la fragmentation peut faire baisser les débits d écritures aléatoires par 2 et les écritures séquentielles par 4(dans certains teste),arrivé a ce stade même un sata 2 ne sera pas plus performant puisque ce sont le débits du SSD qui auront chutes.

Ce message a été modifié par Kalm - 2 Dec 2010, 18:23.

[stephn666]

Merci pour ta réponse, j'avoue que je m'en doutais un peu.
Concernant la fragmentation, je suppose que tu en parle car il n'y a pas encore la gestion du trim dans Mac OS X et que ça pénalise certain contrôleur sous notre OS?

Sinon j'ai lu pas mal de chose sur ce forum et d'autre concernant les SSD et je vois qu'il y en a qui vont ce faire une joie de faire du RAID 0, je n'entends personne parler de la latence, je croyais que ça l'augmentais?

[Kalm]

Merci pour ta réponse, j'avoue que je m'en doutais un peu.
Concernant la fragmentation, je suppose que tu en parle car il n'y a pas encore la gestion du trim dans Mac OS X et que ça pénalise certain contrôleur sous notre OS?

Sinon j'ai lu pas mal de chose sur ce forum et d'autre concernant les SSD et je vois qu'il y en a qui vont ce faire une joie de faire du RAID 0, je n'entends personne parler de la latence, je croyais que ça l'augmentais?

Ces testes ont étés effectués sous commande Trim mis à jour le 17 Septembre 2010.
Raid 0,Effectivement j ai vu certains teste ou l on pouvait remarquer l augmentation de latence et un débit similaire sur certains fichiers.

Ce message a été modifié par Kalm - 2 Dec 2010, 20:52.

[stephn666]

Ces testes ont étés effectués sous commande Trim mis à jour le 17 Septembre 2010.
Raid 0,Effectivement j ai vu certains teste ou l on pouvait remarquer l augmentation de latence sur certains fichiers.

Alors là je n'y comprends plus rien, je pensais que sur mémoire flash il n'y avais pas de fragmentation ou alors ce que tu dit ne sous entend pas ça et que j'aurais mal compris.

Quoi qu'il en sois, même si je suis hors catégorie (sata 1 oblige), je ne manquerais pas faire un bench pour ce topic, j'ai déjà préparer le "avant" qui m'a d'ailleurs bien surpris sur certain test (sur les 4k) par rapport à un SSD et j'ai également été surpris de voir à quel point l'écriture était lente sur mon disque je ne m'en doutais même pas.

Moralité, ce qu'il manque dans les test des SSD c'est plus de comparaisons avec nos vieux disques à plateaux.

[Kalm]

Ces testes ont étés effectués sous commande Trim mis à jour le 17 Septembre 2010.
Raid 0,Effectivement j ai vu certains teste ou l on pouvait remarquer l augmentation de latence sur certains fichiers.

Alors là je n'y comprends plus rien, je pensais que sur mémoire flash il n'y avais pas de fragmentation ou alors ce que tu dit ne sous entend pas ça et que j'aurais mal compris.

C est le wear-leveling gerant l usure sur l ensemble du SSD qui provoque cette fragmentation et qui dégrade les performances en écriture.

Ce message a été modifié par Kalm - 2 Dec 2010, 17:36.

[stephn666]

C est le wear-leveling gerant l usure sur l ensemble du SSD qui provoque cette fragmentation et qui dégrade les performances en écriture.

Ok merci, j'aurais encore appris autre chose aujourd'hui.

[Kalm]

Teste SandForce SF1200 single et RAID-0 ,

http://benchmarkreviews.com/index.php?opti...mp;limitstart=4

[Kierkegaard]

Ces testes ont étés effectués sous commande Trim mis à jour le 17 Septembre 2010.
Raid 0,Effectivement j ai vu certains teste ou l on pouvait remarquer l augmentation de latence sur certains fichiers.

Alors là je n'y comprends plus rien, je pensais que sur mémoire flash il n'y avais pas de fragmentation ou alors ce que tu dit ne sous entend pas ça et que j'aurais mal compris.

C est le wear-leveling gerant l usure sur l ensemble du SSD qui provoque cette fragmentation et qui dégrade les performances en écriture.

En somme, si j'ai bien compris, le wear-leveling contribuerait, d'une part, à gérer l'usure sur l'ensemble du SSD, ce qui semble plutôt une bonne chose et, d'autre part, à fragmenter et à dégrader les performances en écriture sur le SSD, ce qui est un sérieux problème, non?

Ce message a été modifié par Kierkegaard - 2 Dec 2010, 21:34.

[Kalm]

Ces testes ont étés effectués sous commande Trim mis à jour le 17 Septembre 2010.
Raid 0,Effectivement j ai vu certains teste ou l on pouvait remarquer l augmentation de latence sur certains fichiers.

Alors là je n'y comprends plus rien, je pensais que sur mémoire flash il n'y avais pas de fragmentation ou alors ce que tu dit ne sous entend pas ça et que j'aurais mal compris.

C est le wear-leveling gerant l usure sur l ensemble du SSD qui provoque cette fragmentation et qui dégrade les performances en écriture.

En somme, si j'ai bien compris, le wear-leveling contribuerait, d'une part, à gérer l'usure sur l'ensemble du SSD, ce qui semble plutôt bonne chose et, d'autre part, à fragmenter et à dégrader les performances en écriture sur le SSD, ce qui est un sérieux problème, non?

C est le paradoxe,on peut rever a un OS qui puisse gérer correctement ces écritures sur l ensemble des cellules du SSD

Ce message a été modifié par Kalm - 2 Dec 2010, 21:41.

[Kierkegaard]

Ces testes ont étés effectués sous commande Trim mis à jour le 17 Septembre 2010.
Raid 0,Effectivement j ai vu certains teste ou l on pouvait remarquer l augmentation de latence sur certains fichiers.

Alors là je n'y comprends plus rien, je pensais que sur mémoire flash il n'y avais pas de fragmentation ou alors ce que tu dit ne sous entend pas ça et que j'aurais mal compris.

C est le wear-leveling gerant l usure sur l ensemble du SSD qui provoque cette fragmentation et qui dégrade les performances en écriture.

En somme, si j'ai bien compris, le wear-leveling contribuerait, d'une part, à gérer l'usure sur l'ensemble du SSD, ce qui semble plutôt bonne chose et, d'autre part, à fragmenter et à dégrader les performances en écriture sur le SSD, ce qui est un sérieux problème, non?

C est le paradoxe,on peut rever a un OS qui puisse gérer correctement ces écritures sur l ensemble des cellules du SSD

Mais en attendant d'avoir la commande TRIM sur Mac OS X, peut-être pourrait-on avoir un logiciel qui puisse redonner une belle jeunesse au SSD, via un logiciel spécialement conçu pour ce genre d'opération. Ce n'est pas ce que fait justement HDDErase sur PC ou bien j'ai mal compris?

[Kalm]

Il est 4h the stock market closed
Je dors bonne nuit

[stephn666]

C est le paradoxe,on peut rever a un OS qui puisse gérer correctement ces écritures sur l ensemble des cellules du SSD

Mais en attendant d'avoir la commande TRIM sur Mac OS X, peut-être pourrait-on avoir un logiciel qui puisse redonner une belle jeunesse au SSD, via un logiciel spécialement conçu pour ce genre d'opération. Ce n'est pas ce que fait justement HDDErase sur PC ou bien j'ai mal compris?

Bonsoir,
Plûtot que de parler d'un OS qui puisse gérer ça correctement on devrais plutôt parler d'un nouveau système de fichier, ça sera surement d'actualité avant la fin 2010 à mon avis...

Je pense aussi que cette fragmentation est plus ou moins bien géré suivent le contrôleur, avis aux expert.

Ce message a été modifié par stephn666 - 2 Dec 2010, 22:22.

[Guest_anonym_d019ede3_*]

Alors là c'est moi qui ne suis plus non plus...
Ça veut dire que même en reconditionnant son SSD et en le reclonant (ce qui défragmente sur mac) on fragmente malgré tout?!
De plus si ma mémoire est bonne ce n'est pas forcément la fragmentation qui le ralenti le plus mais plutôt les fichier de fichier de.... etc les un dans les autres arrétez moi où je me trompe car je fini par redevenir aussi confus qu'à mon début de renseignements sur SSD

Ce message a été modifié par anonym_d019ede3 - 2 Dec 2010, 22:31.

[Kierkegaard]

À défaut d'avoir le TRIM sur Mac OS X, le meilleur système d'exploitation au monde, ce serait cool d'avoir un équivalent du logiciel HDDErase pour Mac.

[Kierkegaard]

Alors là c'est moi qui ne suis plus non plus...
Ça veut dire que même en reconditionnant son SSD et en le reclonant (ce qui défragmente sur mac) on fragmente malgré tout?!
De plus si ma mémoire est bonne ce n'est pas forcément la fragmentation qui le ralenti le plus mais plutôt les fichier de fichier de.... etc les un dans les autres arrétez moi où je me trompe car je fini par redevenir aussi confus qu'à mon début de renseignements sur SSD

Redonner une pleine jeunesse aux cellules d'un SSD sur Mac, je n'y crois plus du tout. Sur un PC, là, oui. Le programme HDDErase n'a pas encore son équivalent pour le Mac et c'est bien dommage.

[Guest_anonym_d019ede3_*]

Si quelqu'un à des infos d'ailleurs sur futur "LYON" à ce sujet...
Et toi Kierkegaard as-tu re essayé avec la méthode "jason"?
http://jasontomczak.com/2010/06/21/recondi...e-mac-for-free/

Ce message a été modifié par anonym_d019ede3 - 2 Dec 2010, 23:17.

[Kierkegaard]

Si quelqu'un à des infos d'ailleurs sur futur "LYON" à ce sujet...
Et toi Kierkegaard as-tu re essayé avec la méthode "jason"?
http://jasontomczak.com/2010/06/21/recondi...e-mac-for-free/

Les logiciels comme DiskTester qui ont la prétention de reconditionner les SSD ne font, je le crains, que nous vendre du rêve. Sur Mac, il n'existe pas de cure miracle pour redonner une seconde jeunesse aux cellules d'un SSD sur Mac. Sur PC c'est possible mais pas encore sur Mac.

Quand « effacer » signifie en remettre une couche, en l'occurrence « écrire » des zéros partout, il faut arrêter de rêver. Effacer, lire et écrire, ce sont 3 choses très distinctes. Sur nos Mac, on lit et on écrit. Et quand on croit effacer, on écrit des zéros. On parle de SSD, là, pas de HDD.

Ce message a été modifié par Kierkegaard - 2 Dec 2010, 23:28.

[Guest_anonym_d019ede3_*]

Si quelqu'un à des infos d'ailleurs sur futur "LYON" à ce sujet...
Et toi Kierkegaard as-tu re essayé avec la méthode "jason"?
http://jasontomczak.com/2010/06/21/recondi...e-mac-for-free/

Les logiciels comme DiskTester qui ont la prétention de reconditionner les SSD ne font, je le crains, que nous vendre du rêve. Sur Mac, il n'existe pas de cure miracle pour redonner une seconde jeunesse aux cellules d'un SSD sur Mac. Sur PC c'est possible mais pas encore sur Mac.

Quand « effacer » signifie en remettre une couche, en l'occurrence « écrire » des zéros partout, il faut arrêter de rêver. Effacer, lire et écrire, ce sont 3 choses très distinctes. Sur nos Mac, on lit et on écrit. Et quand on croit effacer, on écrit des zéros. On parle de SSD, là, pas de HDD.

Oui et si tu as suivi moi l'effacement seul en soit je l'avais déjà test sans résultat mais c'est l'effacement suivi de création de 16 partitions pour revenir à une seule qui m'a fait retrouver une jeunesse à mon SSD alors bien mal au point 2mn au démarrage!
Par contre là où j'ai séché c'est pour la fin du topic avec la manip pour la création de l'image disque car mon anglais technique est mauvais et que je n'ai pas trouvé comment procéder...
A bon entendeur si tu sais me traduire je ferai bien le test en entier pour voir ce que ça donne.

EDIT: tout le monde "Hallucine" sur cette méthode ou n'en a pas entendu parlé sauf que pour moi elle a déjà alors qu'effectuée seulement en partie fait ses preuves, après qu'on m'explique le pourquoi du fonctionnement de cette méthode ou de celle d'un disk tester je voudrais bien au moins j'aurai référence pour savoir mieux de quoi je parle.

Ce message a été modifié par anonym_d019ede3 - 2 Dec 2010, 23:43.

[Daystrom]

Comme promis voici les teste de mes vertex 2.
En comparaison mon nouveau Western Digital Caviar Black (2To - 7200Tr/min) qui est largement plus rapide que mon ancien raid 0 (2x WD 750Go - 7200Tr/min) et qui est actuellement le HDD 7200 Tr/min le plus rapide du marché.

Western Digital Black 2To 7200Tr/min :

Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch

Vertex 2 seul :

Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch

Vertex 2 en raid 0 (2 disques):

Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch

Ce message a été modifié par Daystrom - 3 Dec 2010, 00:03.

[Kierkegaard]

Si quelqu'un à des infos d'ailleurs sur futur "LYON" à ce sujet...
Et toi Kierkegaard as-tu re essayé avec la méthode "jason"?
http://jasontomczak.com/2010/06/21/recondi...e-mac-for-free/

Les logiciels comme DiskTester qui ont la prétention de reconditionner les SSD ne font, je le crains, que nous vendre du rêve. Sur Mac, il n'existe pas de cure miracle pour redonner une seconde jeunesse aux cellules d'un SSD sur Mac. Sur PC c'est possible mais pas encore sur Mac.

Quand « effacer » signifie en remettre une couche, en l'occurrence « écrire » des zéros partout, il faut arrêter de rêver. Effacer, lire et écrire, ce sont 3 choses très distinctes. Sur nos Mac, on lit et on écrit. Et quand on croit effacer, on écrit des zéros. On parle de SSD, là, pas de HDD.

Oui et si tu as suivi moi l'effacement seul en soit je l'avais déjà test sans résultat mais c'est l'effacement suivi de création de 16 partitions pour revenir à une seule qui m'a fait retrouver une jeunesse à mon SSD alors bien mal au point 2mn au démarrage!
Par contre là où j'ai séché c'est pour la fin du topic avec la manip pour la création de l'image disque car mon anglais technique est mauvais et que je n'ai pas trouvé comment procéder...
A bon entendeur si tu sais me traduire je ferai bien le test en entier pour voir ce que ça donne.

EDIT: tout le monde "Hallucine" sur cette méthode ou n'en a pas entendu parlé sauf que pour moi elle a déjà alors qu'effectuée seulement en partie fait ses preuves, après qu'on m'explique le pourquoi du fonctionnement de cette méthode ou de celle d'un disk tester je voudrais bien au moins j'aurai référence pour savoir mieux de quoi je parle.

Si la méthode de jason a donné de très bons résultats sur ton SSD, c'est tant mieux. Il n'y a rien de mieux que l'expérience pour trancher une question.

Pour l'anglais, pas plus que toi, ce n'est pas non plus ma matière forte. Désolé, j'aurais aimé pouvoir t'aider sur ce coup. J'utilise Google Traduction, ce n'est pas top mais c'est mieux que rien.

[Daystrom]

Suite Vertex 2 en raid 0 (deux disques):

Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch

Vertex 2 en raid 0 (3 disques):

Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch

Ce message a été modifié par Daystrom - 3 Dec 2010, 00:17.

[Guest_anonym_d019ede3_*]

Si la méthode de jason a donné de très bons résultats sur ton SSD, c'est tant mieux. Il n'y a rien de mieux que l'expérience pour trancher une question.

Ben je suis passé de 2mn au démarrage à 31 secondes (chrono de mon portable en main)!
Donc oui résultat significatifs!

et j'avais déjà test effacement par zéros; refo et re clonages avant sans résultats...

Je n'ai testé disk tester qu'après trois jours après cette manip et même si mes bench (testés seulement après la méthode "jason") étaient meilleurs après DT, pas de différences ressenties à l'usage avant lui ou après.

Ce message a été modifié par anonym_d019ede3 - 3 Dec 2010, 00:21.

[Daystrom]

Suite et fin Vertex 2 raid 0 (3 Disques):
Click for large view - Uploaded with Skitch
Click for large view - Uploaded with Skitch

Voilà c'est fini.
Je serais intéressé par les commentaires de nos spécialistes sur le comportement des SSD.
Et que pensez vous du raid dans les cas testé?

[Kierkegaard]

Trois SSD Vertex 2 en RAID, dans un Mac Pro, ça dépote grave.

Ce message a été modifié par Kierkegaard - 3 Dec 2010, 01:03.