Reprise du message précédent :
Même côté perfs j'ai du mal à voir l'intérêt pour un consommateur lambda ...

 
 
 
Tout dépendera de ta charge de travail,si c est pour faire de texte , du surf ,ou même pour y installer le systeme aucun intérêt  .
Par contre en lourde charge lorsque que je bosse sur PS ou Aperture la différence en pratique est très significative.
 
A savoir  que le Garbage collector  fonctionnent Indépendamment de l OS, RAID ou pas  ,le contrôleur du SSD  fait sa sauce en interne
Concernant la commande TRIM sous OS X: en RAID0 logiciel elle est bien active,on peut le vérifier dans info systeme ou en mode Single User en tapant la commande fsck -fy au boot.  
Te concernant si tu es sous Windows ,tu peux tjrs envoyer la commande TRIM en manuel ,je pense que certaines toolbox le font.
 
Ici deux de mes M4 256GB RAID0 Logiciel:partitionnés systeme/Data  
Installation il y a 6mois aucun problème  d instabilité ou de perte de performance sur ttes les bandes.,évidement backup oblige comme  pour un single :-)
 
M4-CT256M4SSD2 :  
 
  Capacité: 256,06 Go (256 060 514 304 octets)  
  Modèle: M4-CT256M4SSD2                            
  Révision: 9  
  Numéro de série: 0  
  NCQ (Native Command Queuing): Oui  
  Profondeur de la file d’attente: 32  
  Support amovible: Non  
  Disque amovible: Non  
  Nom BSD: disk0  
  Type intermédiaire: SSD  
  Prise en charge de TRIM: Oui
  Type de carte de partition: GPT (Tableau de partition GUID)  
  État S.M.A.R.T.: Vérifié  
  Volumes:  
disk0s1 :  
  Capacité: 209,7 Mo (209 715 200 octets)  
  Nom BSD: disk0s1  
  Contenu: EFI  
disk0s2 :  
  Capacité: 64 Go (64 000 000 000 octets)  
  Nom BSD: disk0s2  
  Contenu: Apple_RAID  
Boot OS X :  
  Capacité: 134,2 Mo (134 217 728 octets)  
  Nom BSD: disk0s3  
  Contenu: Apple_Boot  
disk0s4 :  
  Capacité: 191,58 Go (191 582 322 688 octets)  
  Nom BSD: disk0s4  
  Contenu: Apple_RAID  
Boot OS X :  
  Capacité: 134,2 Mo (134 217 728 octets)  
  Nom BSD: disk0s5  
  Contenu: Apple_Boot

Le trim en raid 0 c'est la première fois que je vois ça.
 
Ma fois on en apprend tous les jours même si je trouve ça louche.

En fait c'est Intel qui annonce qu'une prochaine version des drivers serial ATA rst pourrait apporter la compatibilité de la commande trim avec les ssd utilisés en raid. Le support du trim ne concernerait d'ailleurs que le mode raid0. A suivre...

Ceci étant, il n'y a à mon avis pas d'obstacle logiciel à le supporter.

Que le SSD soit indiqué comme prenant en charge le TRIM est une chose, qu'il soit bien actif en est une autre.

Il faut que le pilote traduise les commandes TRIM envoyées par l'OS vers le RAID en commandes TRIM à envoyer vers les SSD. Mais apparemment c'est plus dur qu'il n'y parait vu que personne ne le fait encore

normal les jeux prennent une place folle, mais comme il l'a indiqué, il n'a qu'un seul jeu...

Ce n est pas simplement une info ce qui n  était certes pas probant avant la 10.6.8 je te l accorde.
Lorsque je démarre en single User et que j envoie la commande  fsck -fy ,il applique une réparation du support puis un TRIM des blocs inutilisés  "Trimming unused blocks".des lors que la commande est désactivé cette ligne de commande n apparait plus ainsi que dans info.D ailleurs malgré que  certains SSD supportent la commande TRIM ,elle reste marquée comme non,pas supportée .
http://www.macbidouille.com/news/2 [...] si-le-trim  
je n ai pas Linux,mais certains ont fait le test pour savoir si la commande était bien activée sous OS X et que ce n était pas simplement une notification ,ils ont pourri le SSD sous OS X puis vérifié  sous linux si la commande avait correctement fait son boulot ,avec succès.  
 
Enfin pour conclure ,cela fait 6 mois que mon RAID est configuré et aucune perte des performances sur ttes les bandes 4k 1024k et plus , Random et sequentiel,   vérification avec Speedtools Utility et DiskTester  http://diglloydtools.com/disktester.html
 
Maintenant concernant l usure du SSD  en absence de TRIM,au vu du test de torture fait sur XtremeSystems je ne m affolerai  pas plus que de mesure.:-)

Je viens de commander un Crucial M4 64 Go pour remplacer mon HDD dont les données smart laissent à penser qu'il va claquer sous peu ...
 
Les disques livrés dernièrement sont dans quelle version de firmware ?
 
Ceux ayant tenté la procédure se sont t'il retrouvés avec des "briques" inutilisables suite à un échec ?

le mien a été reçu en 002
j'ai flashé le firmware selon la méthod edécrite en page 1 et aucun soucis, aucun bug (pourtant, comme toi j'avais peur de le foirer)

 
On commence toujours avec un jeu :-)  mais sur Steam lorsque l'on voit des promos avec pour un Crysis du 4 euros, un Call of duty 4 pour autour de 10 euros, une intégrale de BF Bad Company pour 17 euros et j'en passe (là y a 50% sur tous les ARMA II difficile parfois de résister :-)  
 
Enfin bref tout cela pour dire que ca se remplit vite surtout que les jeux à venir grossissent à vue d'oeil  (BF3 prend 16 go)

 
002 ? tu l'as acheté quand  ?

il y a 3 semaines sur amazon (fdp gratuit pour 90.98€)

ouch sacré différence de firmware avec le dernier sorti , bon et bien je verrais ... merci pour le retour

Euh non on est passé du 2 au 9 direct ^^

Rien n empéche de mettre les jeux sur l hdd s il y a .... un ssd ne fait pas gagner des fps, au mieux ça va améliorer des temps de chargement.

reçu en 009 il y a une semaine.

Blague inside    pourrie ! mais pas plus que ta formulation  

quelle est la durée de la garantie Crucial pour les M4 ?
Je suis proche de commander chez Amazon le 128Go mais je vois seulement une durée de 2 ans pour la garantie, ce qui est peu comparé à Rue du Commerce qui indique 5 ans par exemple....

ni l'un ni l'autre  
La garantie est de 3 ans sur le M4.
Ça fait déjà plusieurs mois que RDC/Top Achat annonce une durée de garantie supérieure à la réalité, c'est du foutage de gueule

 
Voici les screen de 2 M4 128GB en RAID0 avant et après le passage en 0009
http://www.derbench.de/index.php/c [...] n?Itemid=0

 
Améliorer le temps de chargement c'est le seul but (hormis le lancement du jeu lui meme)
 
J'ai commencé à noter le changement sous BF2/2142 ou pour la première fois je me retrouve dans les premiers sur la carte (avec mon vieux P4 j'arrivais et certains étaient déja à l'autre bout de la carte dans les avions)
 
Sous BF3 (j'ai juste commencé la partie solo) c'est un plaisir également d'éviter une trop longue attente au chargement
 

oui c'est pas du tout normal et ça n'incite pas à faire confiance aux fiches produits des vendeurs à distance.

Le mieux est de toujours vérifier via le site du constructeur.

Voilà, c est donc pour un besoin spécifique. C e n est pas une obligation.

 
Le prozac c'est parce que j'aurais pu trouver l'info par moi même si j'avais pris la peine de lire

La relation de cause à effet n'est pas prouvée. L'autre hypothèse serait "on s'en branle de quelques geeks qui font du raid 0 avec des SSD donc on le fera quand on aura le temps" .

Sauf que c'est la même chose sur les solutions RAID destinées aux Pro à ma connaissance.

Les solutions RAID Pro c'est l'usage hybride qu'elles visent, et en SLC là où en plus le TRIM est moins critique.
 
Après pour moi si on sais lire les données (i.e. quand on nous demande les secteurs s1 et s2, que l'on sait que l'on va devoir lire les secteur s'1 du SSD1, s''1 du SSD2) je ne vois pas pourquoi on ne peux pas faire la même translation pour le TRIM...
 

+1000 c'est que je me suis toujours dit aussi.    
 
Le raid ne doit pas être une priorité pour eux tout simplement.
C'est dommage, car Sony a montré avec ses dual et quad SSD qu'il y a moyen de faire des trucs très performants tout en étant très compact.

De toutes façons OCZ sait le faire sur ces SSD PCI-e qui ne sont que des contrôleur SAS avec des SandForce au cul, donc même s'il y a un firmware/pilote custom, dans l'absolu ça soit rester possible.

C'est pas forcément de l'usage hybride, ça dépend des besoins, et justement avoir le TRIM permettrait de partir de manière plus sereine sur des SSD avec des MLC classiques.
 
Sinon le prob je pense c'est que si tu as une commande TRIM de l'OS qui te dis de trimmer 64K LBA à partir de la LBA 5464564 tu dois envoyer 32K commandes TRIM de 1 LBA à chacun des deux SSD...  

 
C'est vrai, maintenant j'ai vu personne le tester

Moi non plus, je ne vois pas ce qui pourrait faire obstacle logiciellement parlant.

Pourquoi le faudrait il et ne pas envoyer 2 commandes de 32KLBA en // ?

De tte façon le SSD a mémoire flash" est une solution de transition.
Il y a déjà d autres types de mémoire en développement, voir en début d exploitation commerciale, qui promettent une fiabilité "infinie" (avec des nombre de cycles d écriture qui se comptent en dizaines de millions) et des performances au même niveau, voir supérieures (d autant que l augmentation du nombre de cycles permet d utiliser un wear-levelling bien moins agressif, voir de s en passer totalement).

Parce qu'une commande TRIM indique l'adresse LBA de départ et le nombre d'adresse LBA consécutives à trimmer derrière, vu que les LBA logiques sont réparties physiquement entre les deux SSD tu es obligé de scinder les commandes TRIM

Après j'ai un peu oublié le strip size, avec un strip size de 64 Ko par exemple on passe d'un SSD à l'autre tous les 128 LBA donc une commande pour trimmer 64K LBA logique serait à splitter en 500, pas 32000.

 
Ça dépends du nombre de SSD, et du nombre de LBA a trimmer (et dans une implémentation bette du strip size), mais :
- soit tu suis du LBA de base au LBA de fin et que tu "regardes" sur quel SSD tombe le secteur logique, et que tant que ça ne change pas de SSD tu n’envoie pas le TRIM, au final tu va n'envoyer des commande TRIM que de la taille du strip size.
- soit t'as de quoi mouliner un peu plus longtemps et tu analyse le TRIM dans l'ensemble et tu dois pouvoir ne faire qu'une commande TRIM par SSD...
 

Tout fait ,d ailleurs certaines toolbox permettent d envoyer le commande sur un RAID0.

Tu ne voulais pas plutôt dire "et que tant que ça ne change pas de SSD tu envoie le TRIM" ? Dans ce cas tu ne trim qu'une toute partie.

Je me demande bien par quel miracle.