très intéressant, me permet juste de spécifier qu'un SSD a aussi besoin d'être defragmenté, c'est une croyance populaire qu'il en a pas besoin.
Il en a moins besoin qu'un disque dur.
Defrag agit selon 2 plans bénéfiques pour un HDD:
1) déplace les données à façon d'améliorer les temps d'accès (près du bord du disque, les têtes auront moins de route à faire).
2) réalignent les clusters d'un fichier (par exemple un film) à façon que sa lecture puisse se faire de façon séquentielle, sans ça la lecture serait de type random (aller chercher les clusters éparpillés partout dans le disque).
Pour un SSD defrag est intéressant que pour le point 2.
Comme vous le voyez dans n'importe quel bench de SSD la difféerence entre le performances sequentielles et random peut être importante. Il conviendra alors de temps à autre faire un defrag.
Quant à la durée de vie pour un SSD défragmenté 1 fois par moi vous ne risquez pas de voir sa fin, dans l'hypothèse de l'absourde si vous avez 50 GB et vous defragmenté tous les jours votre SSD va tout de même vivre plus que 100 ans.

merci de ces précisions, je me demandais s'il était utile de défragmenté un SSD, puisqu'il n'y a pas de temps d'accès dû aux têtes.
Et "swapper" un SSD, ça donne quoi ?

Le problème de la fragmentation intervient surtout quand un fichier dépasse les 1000 ou 10000 fragments. J'ai ici sous les yeux un système avec des fichiers de plus de 100.000 fragments. A ce niveau Windows commence à avoir des problèmes pour gérer les extensions.

100.000 fragments ... il serait de défragmenter quand même !

il est vrais que généralement pour les mémoires, les burst (opérations sur des addresses contigues) sont plus rapides ...

Pour la SD-RAM ça l'est en tout cas, après je ne suis pas un spécialiste de la mémoire flash et de son fonctionnement (mais il y'a au moins un gain sur les communications car il n'y a pas besoin de redonner l'adresse à chaque fois, il suffit de dire qu'il faut incrémenter)

me permet juste de spécifier qu'un SSD a aussi besoin d'être defragmenté, c'est une croyance populaire qu'il en a pas besoin.
Il en a moins besoin qu'un disque dur.



Désolé mais ce n'est pas correcte. La défrag sur un SSD ne sert à rien. A quoi sert la defrag sur un HDD ? A rapprocher le plus près possible les même données pour éviter la déplacement du peigne de lecture.


Sur un SSD il n'y a pas de peigne. De plus le temps d'accès est identiques sur toutes les cellules.

Accéder à la première zone de mémoire et en suite à la dernière zone de mémoire prend le même temps que d'accéder à la première zone puis à la seoncde.


C'est pourquoi la défrag est inutile et c'est pourquoi c'est très bien d'annuler la defrag automatique sur les SSD

Après les P4 qui accélèrent l'internet, voilà Windows qui accélère votre disque dur...

Bon, sarcasme mis à part, je trouve ça intéressant que Microsoft s'intéresse à cet aspect. Dommage qu'ils essayent d'imposer leur technologie aux fabricants au lieu de s'adapter purement de façon logicielle aux caractéristiques techniques des SSD...

sinon j'ai envie de dire merci pour la pub qui ne veux pas s'enlever et qui m'empeche de lire la news :s

Quelle pub exactement ? On a besoin de détail pour régler le problème.

Quelle technologie essaye t'il d'imposer ?
Moi je lis que de façon logicielle il vont récupérer les infos que donne le ssd (dans la dernière version de la norme ATA) et en fonction de ça W7 ecrira à l'endroit le plus adéquat sur le disque.
Savoir lire c'est bien, comprendre ce qui est écrit c'est mieux.

J'ai lu :

J'en ai déduit que le SSD doit être mis à jour/pensé pour comprendre cette fonction là du NTFS. Si c'est à comprendre dans l'autre sens et que le SSD en ATA-8 inclue cette fonction là d'origine, mea culpa.

Perdu.
Il est faux de penser que des données contigues sur la flash permettent une lecture plus rapide. En particulier si la taille des clusters font un multiple de la taille d'un secteur de NAND (ce qui devrait être le cas, même aujourd'hui).
C'est parce que la technique de wear levelling nécessite forcemment une table de translation en interne dans le SSD afin de dire que l'écriture/lecture du bloc A se trouve dans le secteur X de la NAND. De plus A et X ne sont pas linéaire, mais variable (on écrit dans A, mais X est un secteur très utilisé, donc on écrit dans le secteur Y de la NAND, et on dit que A => Y). Bref, même des données contiguent ne le sont pas en NAND.
Autre point intéressant, si le SSD sait que le secteur contient des données inutiles, son contrôleur peut très bien effacer le secteur en avance. A mon avis cette information (secteur à effacer) pourra très bien être implémenté dans d'autres filesystem (ext, FAT, etc.).
Sur la NAND, l'effacement d'un secteur est très long (se compte en ms), puis vient l'écriture des données (l'écriture est rapide, mais la vérification que l'écriture prend plus de temps), et pour finir la lecture (se compte en µs). Heureusement il y a une RAM pour accélérer tout ça...
Dernier point, la durée d'un SSD dépend du nombre d'écriture permis par secteur avant erreur (de l'ordre de 10000, parfois 100000), et de la marge de secteur supplémentaires invisibles servant au wear levelling (de l'ordre de 10%). En supposant un wear levelling parfait (un secteur est ré-écrit seulement une fois le SSD entièrement rempli), un SSD de 100Go (incluant la marge), un débit en écriture constant de 100Mo/s, et un nombre d'écriture moyen d'un secteur avant erreur de 10000, tu as:
- le disque est rempli au bout de 1024s.
- un secteur sera ré-écrit 10000 fois au bout de 10240000s
- soit au bout de 118 jours environ.
Donc à mon avis, un SSD défragmenté tous les jours (qui ne va pas déplacer tout les fichiers tous les jours), ça pourrait tenir au moins 30x118j, soit presque 10 ans...

Oui il existent des optimisateur di RAM que notamment defragmentent la RAM.

vodnok3 t'as tout à fait raison, le SSD n'a pour rien besoin de être defragmenté dans une optique selon le point 1) càd déplacer les fichier pour en optimiser les temps d'accès. Ce que je ne comprends pas c'est pourquoi tu reprend ce que j'ai dit. C'est bien pour le poin 2) que defrag est utile au SSD.

Fuli10, on parle bien du point 2) lecture sequentielle ou random.
et bien comme introduction je précise qu'il n'y a pas de gangant ou perdant, comme il n'y a pas besoin de parler compliqué lorsqu'on connaît bien les choses.
Je te propose de procéder simplement, de façon cartésienne:
On est bien d'accord que le SSD va plus vite en sequentiel que en random.
A partir du moment ou on le reconnaît que en random le SSD est plus lent, devient compréhensible l'intérêt de favoriser l'utilisation du SSD le plus possible en séquentiel.
Comment?
Faudra aussi m'expliquer pourquoi faire un backup de 80GB en SSD on le fait quelque minute plus vite avec le SSD defragementé que non-defragmenté.

Côté write endurance, 10 ans, cela dépend du contrôleur, et de la puce (MLC ou SLC). Il y a des entreprises avec contrôleur propriétaire, qui améliorent le problème de write amplification, ont 2 niveaux de wear leveling, jusqu'à arriver à un mini-ups integré en cas de panne de courant.
Après avoir reconnu ça il devient délicat généraliser une write endurance pour chaque SSD, mais si on reste avec les pieds par terre, ça ne sera pas defrag qui va tuer le SSD. Avant peut être le disque dur-laser.
Bien à vous

Et pourquoi il ne participent pas tout simplement au fs déjà existant?
http://linuxfr.org/2008/04/04/23938.html

Très bon point, efranchi...
quelqu'un a un contre-argument pour le contredire?
à savoir si la défragmentation de SSD sert à quelque chose ou pas...

Je reviens avec les fichiers très fragmentés par exemples de gros fichiers logs comme ceux d'Oracle. On a tres vites des fichers de centaines de megas créés parallèlement sur les disques ce qui engendre de la fragmentation monstre. Et c'est là que l'OS peine. Le même phénomène se produit sur des partitions où sont recréés quotidiennement des centaines de fichiers de tailes variables. Le free-space devient fragmenté au point que l'OS a du mal à créer des fichiers de plusieures dizaines de megas. Dans les deux cas l'OS s'empêtre dans la gestion des pointeurs et fait exploser la taille des directories elles-même.

comment se fait-il qu'OCZ déconseille formellement d'effectuer des défragmentations si c'est si bénéfique?

En même temps lorqu'on parle de défragmentation, il est bon de rappeler qu'elle est inutile avec un système de fichiers digne de ce nom. C'est à dire autre chose que NTFS/FAT. Ext par exemple provoque une fragmentation si faible que la défragmentation est tout simplement inutile.

Je me demande plutôt pourquoi des factories avec contrôleur proprietaire conseillent defrag!
Probablement OCZ le déconseille pour 2 raison possible:
1) celui qui vous a dit ça n'est pas compétent: ceci est compatible avec le fait que OCZ ne développe pas son propre contrôleur, mais l'achète déjà fait chez Jmicron. (c'est un peu comme demander à Alcoa -qui fabrique chassis pour voitures- de vous expliquer un détail sur le fonctionnement des centralines -fabriquées par boesch-).

2) parce que il y met des heures! Plus qu'un HDD classique et le client va pas être content! Et on risque de démasquer la pseudo-arnaque qui se profile derrière le contrôleur Jmicron acheté chez OCZ.

On a eu pas mal de clients qui se sont plaint de la lenteur en multitasking. Il me disent, "Mon OCZ dès que je ouvre quelque fenêtre il plante", en réalité il ne plante pas, il est très lent et semble planter.
Les jmicron sont les plus bon marché mais il ne faut pas trop leur demander, vous en mettent pleine la vue avec des beaux graphiques de perf séquentielles, et puis il sont pire que les HDD en temps d'accès et en IOPS!
write access time OCZ: pic à max 882,00ms!
write access time Intel X-25E (la F1 des SSD): pic à max 0.81ms
write access time HDD WD Caviar (banal disque dur): pic à 12,80 ms.

un si mauvais score on l'atteint seulement quand la cache est vide et les puces sont MLC, mais tu comprends vite que si tu as 80 GB à defragmenter avec de tel pic...ça va être long, l'écriture d'un fichier fragmenté dans ce pic mauvais est de 14,6MB/s...!

IOPS (en conditions réelles) OCZ: 36,64
IOPS Intel: 34'086.76 (pratiquement à lui seul presque plus IOPS qu'un FusionIO!)
IOPS WD Caviar: 127.63

Franchement les Jmicron-SSD avec 36,64 IOPS (512B block size, 100%random, 80%read, 20% write, 16 outstandings) ou est-ce que veut aller?
Dans un serveur? impossible, tout va planter,
Dans un PC? Bonjour le multitasking, le defrag et le backup!
Dans une PS3? bonjour le back up

Exemple PS3:
Formatage avec IntelX25-E: 1 sec
Formatage Memorght GT: 1,4 sec
Formatage avec OCZ: 1min30, idem avec le SSD memory corp et Gskill, tous des Jmicron-SSD
Backup avec Intel SSD: 6min30
Backup avec Memoright GT: 7min
Backup avec Jmicron SSD: 97 min.

Le hic c'est que le memoright a des perf de lecture séquentielle nettement moins bonnes que le OCZ, et pourtant sur le terrain le foudroie, pourquoi? La réponse est dans les IOPS.

Je trouve curieux que le nom de ce contrôleur commence par J, Jmicro, com J, Jackie's touch...

Attention aux SSD-Jmicron, si vous avez un WD raptor ou velociraptor, ne l'changez pour rien au monde avec un Jmicron SSD, même de 3ème génération soit-il!

Ce qui est encore plus triste dans l'histoire c'est que les manager même sont persuadé, comme les clients OCZ, d'avoir un bon SSD.

OCZ, G.Skill, Memory Corp, Solidata, toutes des usines à Jmicron-SSD, et y en a encore. Même ldlc à son propre SSD, le ldlcSSD! Ils nomment un manager responsable qui assemble puce et contrôleur, et vont prendre le contrôleur le seul disponible, le Jmicron, ça coute vachement moin chèr que de le dévélopper soi-même!
Il est souvent arrivé que de tel manager me contacte pour que je leur dise ce que je pense de leur ssd, je vous assure que ces managers initialement sont persuadé d'avoir le meilleur SSD, le dernier depuis la chine, avec qui j'ai eu à faire pour Solidata X1 (reconnu par le gestionnaire des périphériques comme Jmicron H/W Raid0) me disait qu'il était même mieux qu'un Intel SLC! Pas en mauvaise fois, son distributeur USA (dvnation) vous dira que même le solidata X2(MLC) est mieux que le Intel SLC! Pas en mauvais fois non plus, ils sont vraiment persuadé, car regardent seulement les données séquentielles.
Jmicron leur dit qu'il aura 210/200 MB/s, et 15'000 IOPS (vrai, mais sans spécifier que ces 15'000 iops sont mésurés dans des conditions jamais réelles!) et puis vous vous retrouvez avec un épave qui arrive à peine à 100 IOPS en condition réelle!
C'était la douche froide pour mes clients, de même pour ces manager.

Vous trouverez toute ces donnés sur mon site ou encore dans quelque semaine sur la chart de tom's (http://www.tomshardware.com/charts/flash-ssd-charts/Database-I-O-Benchmark-Pattern,720.html).

Pour finir, si vous faites defrag 1/mois vous aurez un fonctionnement du SSD env de 70% séquentiel et 30% random (et ce, en tenant compte du "panachage" fait par les algorithmes "anti-usure).

Si vous utilisez le SSD dans un serveur vous arriverez vite à un 100% random, (avant d'acheter regardez bien les perf random, pas séquentielles, et surtout, surtout, les IOPS).

Enfin une vraie info interessante sur 7 ! Cela n'était pas arrivé depuis longtemps, tant d'habitude se sont souvent des suppositions "à prendre avec des pincettes" !

On ferait mieux de laisser l'OS gérer la flash et le wear-leveling avec des FS adaptés ...

Au cas où : il s'agit de la pub en flash Sony ("Blu-ray, etc...). C'est vrai que quand elle s'affiche, on ne voit plus la news, et il faut recharger la page pour qu'elle s'en aille enfin.
@+

merci

Vu les CPU qu'ils utilisent dans les SSD pour ça (et en dehors du fait que modifier les FS est pas anodin), l'impact sur les perfs serait assez élevé.