[RÉSOLU] SSD OU DD

[MyKe]

Bonsoir,

j'ai actuellement un Western Digital Caviar Green SATA III 1To avec une partition de 100Go pour le système + le reste pour les datas!

L'accès aux fichiers ne me convient pas, manque de rapidité !!

J'envisage de passer aux SSD ... ou ?,

Par exemple, un 128Go pour le système et mon WD 1To pour les datas!

MAIS... cela ne va rien changer à temps d'accès sur mes datas ? ! vu que le SSD sera simplement pour le système + logiciels !

Donc à votre avis ?

gros ssd (partitionné) et "pourquoi pas un raptor ?"

J'ai besoin de 270Go pour le système + les datas que j'utilise tout le temps!

Config en signature*

Merci

[treflemard]

Bonjour,

les disque dur "green" ne tourne qu' 5400 trs/min contre 7200 trs/min pou les disques durs "normaux". Il est déconseillé d'installer un système sur un disque 5400 trs/min

Personnellement, si tu as besoin d’accéder très souvent à des données, je dirais SSD pour le système + disque dur 7200 trs/min pour les données que tu veux utiliser souvent et le 5400trs/min pour du stockage pur.

[Carpe_Diem]

Oui, on ne pose pas l'OS sur du 5400 tours. Il y a plusieurs solutions :

- un nouveau HDD en 7200 tours pour y poser données + OS et applications. Le Green pouvant alors servir pour la sauvegarde par exemple. C'est une solution classique qui coûtera dans les 100€.

- un nouveau SSD en 120 Go pour y mettre appli et OS, les données restant sur le Green actuel. Mais cela n'accélérera pas l'accès aux données.

- idem mais avec en + un HDD en 7200 tours. Soit environ 220€

- un petit SSD comme le Corsair Accelerator en 30Go qui sera monté en SSD caching (techno SRT) compatible avec le Z68 de ta CM et ton I7. Solution à 65€ environ.

[MyKe]

En effet je n'avais pas réalisé que les caviar green tourne à 5400 ! quel C¤¤ !!

Cela explique beaucoup de choses,

Maintenant je me pose la question sure: un WD Raptor 300go (avec une partition pour le système + le reste pour mes datas) et quand les SSD de grosse taille seront abordables, je passerai le pas

Qu'est-ce que vous en pensez ?

[Carpe_Diem]

Un Vélociraptor en 300Go vaut 140€. Et par la suite un HDD 1To disons dans les 70€ quand les prix seront revenus à la normale (si jamais ils y reviennent ??). Soit 210€ dépensés.

Quiite à ne pas prendre de SSD, j'en reviens à un HDD de 1To à 7200 tours pour environ 100€ avec le Green en sauvegarde.

[MyKe]

Entre le raptor et le dd 7200tr il y a une grosse différence de performance non ?

[Carpe_Diem]

Grosse non, visible, oui.... mais à quel prix !

J'ai un Raptor et un Vélociraptor ancienne génération et un Caviar Black 7200 tours.

[MyKe]

Je n'ai toujours pas choisi, grrrr

Je me demande quel difference entre un VelociRaptor SATA III 6 Gb/s - 1 To - 64 Mo

et un Seagate Momentus XT - SATA III 6 Gb/s - 750 Go ?

[RoCKeTs]

A savoir qu'un velociraptor ou même un caviar black c'est nettement plus bruyant qu'un caviar green.

C'est juste au cas où les nuisances sonores ont une importance pour toi.

[Kori]

Il y a un fossé entre un ssd et un HDD même un raptor !

J'ai tourné avec un raid0 de raptor avant de passer au SSD.

Pour l'accès aux données tu as validé l'indexation ?

[Carpe_Diem]

Le Momentus XT 750Go est à 140-150€ (note qu'il est en 2,5")

Comme dit en début de sujet, je préfère un HDD 7200 tours + un SSD Caching et garder le Green pour les sauvegardes ou en cas de débordement du HDD 7200 tours.

Ce qui ferait par exemple :

Corsair Accelerator 30 Go Sata II : 55€

Caviar Blue 1 To Sata III cache de 32Mo (le cache profitera du Sata III, pas les plateaux) : 85€

ou un Caviar Black 1 To Sata III cache de 64 Mo : 109€.

Entre 150€ pour une solution hybride et 140€ ou 160€ pour une solution distincte, je préfère la seconde car elle limite les risques en cas de perte du SSD ou du HDD.

Il faudra remonter l'OS et les applis sur le 7200 tours (il devra être le seul branché). Puis, après reboot(s), mettre à jour les SRT et INF d'Intel et enfin brancher le SSD en caching.

[leberger]

En tous cas, si tu installe ton OS sur un SSD, tu verra très très nettement la différence par rapport à un HDD.

Exemple: pour BF3, maintenant je suis quasiment toujours le premier a jouer alors qu'au bout de 30 sec à 1 min, les autres joueur peuvent jouer !

Exemple2 : le démarrage avec un SSD, c'est comme si tu venais juste d'installer l'OS (même si tu as plein de logiciels d'installés).

Donc acheter un SSD pour l'OS et les logiciel que tu utilise très souvent tu auras de bonne performance. Pense à changer le répertoire par défaut de "Mes Documents" et des fichiers que tu télécharge sur le net, ce qui te permettra d'acheter un SSD avec une plus petite capacité (120 Go largement suffisant pour plusieurs jeux installés).

[Kori]

gros ssd (partitionné)

J'avais loupé ce passage, on ne partitionne jamais un SSD. C'est contraire à son mode de fonctionnement (trim).

A ta place je partirais sur :

- un SSD 120 Go -> système + softs divers

- Une partition de 150 GO sur ton hdd pour les datas. Comme ta partition sera en début de disque, ce seront les fichiers les plus rapides d'accès.

- Le reste du HDD -> stockage, fichiers temps os et navigateur etc...

[MyKe]

Merci, je prends note de tous vos commentaires,

Dans une 1er temps je vais prendre un ssd pour l'os: (surement un: Samsung Serie 830 - 128 Go)

"A savoir, a l'installation de l'os, j'utilise un script qui déplace le contenu de dossier utilisateur, sur la partion D:"

Donc sur le ssd, il y aura juste, OS, Logiciels,

[John Shaft]

J'avais loupé ce passage, on ne partitionne jamais un SSD. C'est contraire à son mode de fonctionnement (trim).

Sauf qu'avec Seven, il est de facto saucissoné à l'INstallation avec la partoche de 100 Mo réservée au système (m'enfin bon elle sert jamais cette partition)

[Kori]

Euh j'avais même pas fait gaffe à ce truc, merci

Ce qui ne change rien, puisque non utilisée, et de taille ridicule. Elle n'a pas besoin du trim.

[Latios]

J'avais loupé ce passage, on ne partitionne jamais un SSD. C'est contraire à son mode de fonctionnement (trim).

Non, c'est faux. Le partitionnement ne gène en rien le TRIM, c'est purement software, le disque n'en a absolument pas conscience et ça ne change rien du tout pour lui.

[RinDman]

+1 Le SSD est organisé aléatoirement et non en cluster ... Donc il n' y a aucun INPact :)

[Kori]

La trim répartit les données sur l'ensemble du disque, afin d'égaliser l'usure des cellules.

S'il est partitionné comment cette organisation se fera correctement ?

De plus les partitions ne servent à rien, puisque le temps d'accès sur un SSD est quasi nul.

Edit : petite précision au cas où. je ne prétends pas avoir la science infuse, ce point est une pure déduction de ma part. Suite à mes lectures sur le fonctionnement du trim

[Latios]

Comme je l'ai dit, le SSD n'a pas conscience du partitionnement. C'est uniquement l'OS qui s'en occupe.

De plus, ce dont tu parles c'est le wear-leveling. Le TRIM c'est une magouille qui permet à l'OS de dire au SSD "ok, le block de donné situé a tel adresse n'est plus utilisé, tu peux effacer la cellule qui était utilisée pour ce block et la remettre dans ton pool de cellule libre", et ça a justement pour objectif de permettre au wear-leveling de bien faire son boulot.

Et je vois pas le rapport entre les partitions et le temps d’accès . Une partition c'est fait pour découper un disque physique en plusieurs disques logique, et c'est utile quelque soit le support. Si je veux un dual boot Linux + Windows, je fais deux partitions sur mon SSD

[Kori]

Ça me gêne un peu d epolluer ce topic. Mais le sujet est tellement passionnant...

Comme je l'ai dit, le SSD n'a pas conscience du partitionnement. C'est uniquement l'OS qui s'en occupe.

De plus, ce dont tu parles c'est le wear-leveling. Le TRIM c'est une magouille qui permet à l'OS de dire au SSD "ok, le block de donné situé a tel adresse n'est plus utilisé, tu peux effacer la cellule qui était utilisée pour ce block et la remettre dans ton pool de cellule libre", et ça a justement pour objectif de permettre au wear-leveling de bien faire son boulot.

Le partitionnement affecte des données à une plage utile du disque (ssd ou hdd). Si tu dis telles données ne seront placées que sur les X premiers secteurs. Elles ne pourront être écrites sur une autre partie physique. C'est selon moi le principe des partitions. D'où ma réaction face au trim (ou au wear-leveling je ne connaissais même pas ce nom :sic:).

Et je vois pas le rapport entre les partitions et le temps d’accès .

Facile les bords des plateaux sont plus rapides d'accès, on a toujours utilisé ce principe pour optimiser l'accès au données sur un hdd. Les têtes ayant moins de déplacement à effectuer, elles se placent plus vite. C'est aussi ce principe qui a donné naissance au short stroking.

[Latios]

Le partitionnement affecte des données à une plage utile du disque (ssd ou hdd). Si tu dis telles données ne seront placées que sur les X premiers secteurs. Elles ne pourront être écrites sur une autre partie physique. C'est selon moi le principe des partitions.

Tout à fait, et tout ça, c'est au niveau de l'OS. Le contrôleur du SSD il map les secteurs/blocks aux cellules physique de la mémoire flash, en fonction du nombre d'écriture de celles-ci. Et c'est pas parce que tes données sont sur les premiers secteurs qu'elles seront obligatoirement sur les mêmes cellules. Le contrôleur conserve le nombre d'écriture qu'il y a eu sur chaque cellules, et garde une table de correspondance entre les N° de blocks et les N° de cellules. À chaque écriture sur un block, il affecte une cellule parmi celles ayant subies le moins d'écriture, ce qui a pour effet de niveler le nombre d'écriture. Le TRIM supprime juste l'association entre un block et une cellule, de telle sorte que le SSD peut réutiliser cette cellule pour un nouveau block.

Dans le cas d'un disque dur classique, il se passe des choses un peu comme ça aussi, quand le contrôleur du disque ré-alloue un secteur défectueux à un autre garder libre en cas de secours, mais la plupart du temps la correspondance est immédiate.

À noter que même avec une seule partition, les données ne sont pas forcément réparties sur toutes la plage disponible, ça dépend des systèmes de fichier, de la politique d'allocation, etc. Et il y a de forte chance pour que les méta données du système de fichier (table d'allocations des fichiers, etc.) soient réécrites souvent, et c'est probablement toujours sur les mêmes blocks/secteurs. Mais sur un SSD c'est pas toujours sur les mêmes cellules, puisque le wear-leveling va en sélectionner de nouvelles pour pas user toujours les mêmes.

Voilà, j'espère que c'est plus clair

[Kori]

Le TRIM supprime juste l'association entre un block et une cellule, de telle sorte que le SSD peut réutiliser cette cellule pour un nouveau block.

Le trim ne supprime rien du tout, c'est une fonction d'information. Concernant l"utilisation des données dans les cellules.

Selon les firmwares des SSD, le wear liveling (ça y est je sais ce que c'est ) nivellera sur l'ensemble du disque ou pas.

D'où des perfs plus ou moins constantes dans le temps, selon les modèles.

En informatique, TRIM est une commande qui permet à un système d’exploitation d'indiquer à un contrôleur de disque de type mémoire flash (SSD) quels blocs de données ne sont plus utilisés et peuvent donc être effacés. Cette commande améliore les performances d'accès aux disques SSD.

En résumé nous sommes d'accord sur un point. Les partitions cloisonnent les données, dans des espaces déclarés et physiques.

Donc les partitions diminuent d'autant l'efficacité du wear livelling (qui lui même découle des commandes du trim, d'où l'amalgame souvent utilisé pour décrire cette fonction).

Source wikipédia : http://fr.wikipedia.org/wiki/TRIM

[Latios]

Le trim ne supprime rien du tout, c'est une fonction d'information. Concernant l"utilisation des données dans les cellules.

Relis ce que j'ai dit :

Le TRIM supprime juste l'association entre un block et une cellule, de telle sorte que le SSD peut réutiliser cette cellule pour un nouveau block.

J'ai jamais dit qu'il supprimait les données. C'est le système de fichier (donc l'OS) qui supprime les données, et en informe le SSD par un TRIM sur les blocs affectés.

Et par ailleurs, un TRIM efface complétement le bloc de cellule en question.

Donc les partitions diminuent d'autant l'efficacité du wear livelling

Non !

On va prendre un exemple simplifié : un SSD avec 4 blocs/secteurs et 4 cellules physique, chacun de taille 4096 octets.

Au niveau de l'OS les blocs ont pour adresses 0, 1, 2, 3. Les cellules physiques de la mémoire flash ont pour adresses 0, 1, 2, 3.

Quand le SSD est neuf et n'a jamais été utilisé, toutes les cellules ont 0 écriture.

On fait deux partitions sur les SSD :

1ére partition : blocs 0 et 1

2éme partition : blocs 2 et 3

Ça c'est l'OS qui fait sa sauce, le SSD n'est absolument pas au courant et ne sais pas ce qu'est une partition.

1. On écrit un fichier sur la 1ére partition, disons que le système de fichier le met dans le 1er bloc, adresse 0. Le contrôleur du SSD va lui associer une cellule physique et écrire les données sur cette cellule. Comme toutes les cellules ont 0 écriture, on va supposer qu'il prend la 1ére : adresse 0.

On a donc le mapping suivant :

bloc 0 -> cellule 0

Et le nombre d'écriture suivant :

cellule 0 : 1 écriture

les autres : 0 écriture

2. On écrit un fichier sur la 2éme partition, le système de fichier le met dans le 1er bloc de la partition, adresse 2. Le contrôleur du SSD lui associe une cellule parmi celles qui ont subies le moins d'écriture, on va dire qu'il prend la 1ére, celle d'adresse 1.

Le mapping est donc maintenant celui-ci :

bloc 0 -> cellule 0

bloc 2 -> cellule 1

Et les écritures :

cellules 0 et 1 : 1 écriture

cellules 2 et 3 : 0 écriture

3. On modifie le fichier qu'on a écrit en 1. sur la 1ére partition, pour le système de fichier c'est toujours dans le bloc 0. Il envoi un ordre d'écriture au SSD qui va associer une nouvelle cellule au bloc 0 parmi celles qui ont subies le moins d'écriture, on va dire que c'est la 2.

Nouveau mapping :

bloc 0 -> cellule 2

bloc 2 -> cellule 1

Et les écritures :

cellules 0, 1, 2 : 1 écriture

cellule 3 : 0 écriture

4. On efface le fichier qu'on a écrit sur la 1ére partition, le système de fichier en informe le SSD par un TRIM du bloc 0. Le contrôleur du SSD va donc supprimer l'association entre ce bloc et la cellule physique correspondante et effacer la cellule (la 2).

Le mapping résultant est donc :

bloc 2 -> cellule 1

Et le nombre d'écritures est inchangés :

cellules 0, 1, 2 : 1 écriture

cellule 3 : 0 écriture

5. On réécrit un truc sur la 1ére partition, le système de fichier le met sur le 1er bloc libre : le bloc 0. Le contrôleur du SSD prend une cellule libre parmis celles qui ont le moins d'écritures, la 3.

Voici le nouveau mapping :

bloc 0 -> cellule 3

bloc 2 -> cellule 1

Et le nombre d'écritures :

cellules 0, 1, 2, 3 : 1 écriture

Je pourrais continuer comme ça pendant des heures, mais je pense que ça suffit pour illustrer le problème (du moins j'espère ). Les numéros de blocs tels que vu par l'OS sont indépendant des numéros des cellules physique de la flash du SSD, le contrôleur du SSD conserve la correspondance entre les deux, et ces correspondances changent au grès des écritures. Seul l'espace des numéros de blocs est partitionnés, et ça n'a aucune influences sur l'espace des numéros de cellules de la mémoire flash.

Dans l'exemple au dessus, le bloc 0 de la 1ére partition est tour à tour attribuée a la cellule 0 (qui serait dans la 1ére partition des cellules si elles étaient partitionnées -- ce qui n'est pas le cas) et aux cellules 2 et 3 (qui serait dans la 2éme partition).

Voilà, si là c'est pas plus clair pour toi, je sais pu quoi faire

[elite7words]

Salut, comme beaucoup ici je te conseille de prendre un ssd de 120go pour le systeme et les logiciels courants. Pour les donnees prend un disque dur à 7200rpm (tu peux conserver le tien dans un premier temps, le ssd va déjà bien ameliorer ton ressenti).