Reprise du message précédent :
c'est parfait

Pour le débit brut c'est vrai. En revanche ça n'empêche pas ses applis de se lancer quasi instantanément

 
Oh que oui je vois la difference ! Demarrage/arret/acces c est top
 
Je peux maintenant me permettre de l utiliser normalement. Pour un pc de 2005...

C'est mieux que rien ... moi, le controleur SATA2 de mon nForcePro ne le voit même pas

 
c'est sur.
 
Je pousse au max ste config... Je peux encore ajouter 1go de ram   le pentium M a pas tant de mal que ca

On sous estime souvent la puissance d'une machine à cause des accès du sous système disque et des temps réseau, je suis d'accord

Je sais pas trop si c'est l'ext4 qui s'est "auto-détruit", mon M4 qui agonise ou le controleur SATA qui part à la retraite, mais j'ai droit à toutes sortes de messages d'insultes dans mes logs (accessoirement, l'OS plante après 3min d'usage en ligne de com') depuis ce matin.
 
 
[  650.797970] journal commit I/O error
[  650.797985] journal commit I/O error
[  650.798321] EXT4-fs error (device sda1): ext4_put_super:886: Couldn't clean up the journal
[  843.419510] ata1.00: exception Emask 0x10 SAct 0x7fffffff SErr 0x400101 action 0x6 frozen
[  843.419514] ata1.00: irq_stat 0x08000000, interface fatal error
[  843.419517] ata1: SError: { RecovData UnrecovData Handshk }
[  843.419519] ata1.00: failed command: WRITE FPDMA QUEUED
[  843.419524] ata1.00: cmd 61/10:00:50:30:00/00:00:01:00:00/40 tag 0 ncq 8192 out
[  843.419524]          res 40/00:1c:10:23:00/00:00:01:00:00/40 Emask 0x10 (ATA bus error)
[  843.419526] ata1.00: status: { DRDY }
[  843.419528] ata1.00: failed command: WRITE FPDMA QUEUED
[  843.419532] ata1.00: cmd 61/40:08:78:33:00/00:00:01:00:00/40 tag 1 ncq 32768 out
[  843.419532]          res 40/00:1c:10:23:00/00:00:01:00:00/40 Emask 0x10 (ATA bus error)
[  843.419534] ata1.00: status: { DRDY }
[...]
[  843.419763] ata1.00: status: { DRDY }
[  843.419766] ata1: hard resetting link
[  843.736017] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  843.736727] ata1.00: configured for UDMA/100
[  843.752032] sd 0:0:0:0: >[sda]  
[  843.752034] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  843.752036] sd 0:0:0:0: >[sda]  
[  843.752037] Sense Key : Aborted Command [current] [descriptor]
[  843.752040] Descriptor sense data with sense descriptors (in hex):
[  843.752042]         72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00  
[  843.752049]         01 00 23 10  
[  843.752053] sd 0:0:0:0: >[sda]  
[  843.752054] Add. Sense: No additional sense information
[  843.752057] sd 0:0:0:0: >[sda] CDB:  
[  843.752058] Write(10): 2a 00 01 00 30 50 00 00 10 00
[  843.752064] end_request: I/O error, dev sda, sector 16789584
[  843.752068] quiet_error: 2 callbacks suppressed
[  843.752070] Buffer I/O error on device sda1, logical block 2098442
[  843.752071] lost page write due to I/O error on sda1
[  843.752077] Buffer I/O error on device sda1, logical block 2098443
[  843.752078] lost page write due to I/O error on sda1
[  843.752088] sd 0:0:0:0: >[sda]  
[  843.752090] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  843.752091] sd 0:0:0:0: >[sda]  
[  843.752093] Sense Key : Aborted Command [current] [descriptor]
[  843.752095] Descriptor sense data with sense descriptors (in hex):
[  843.752096]         72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00  
[  843.752103]         01 00 23 10  
[  843.752107] sd 0:0:0:0: >[sda]  
[  843.752108] Add. Sense: No additional sense information
[  843.752110] sd 0:0:0:0: >[sda] CDB:  
[  843.752111] Write(10): 2a 00 01 00 33 78 00 00 40 00
[  843.752117] end_request: I/O error, dev sda, sector 16790392
[  843.752119] Buffer I/O error on device sda1, logical block 2098543
[  843.752121] lost page write due to I/O error on sda1
[  843.752123] Buffer I/O error on device sda1, logical block 2098544
[  843.752124] lost page write due to I/O error on sda1
[  843.752127] Buffer I/O error on device sda1, logical block 2098545
[  843.752128] lost page write due to I/O error on sda1
[  843.752131] Buffer I/O error on device sda1, logical block 2098546
[  843.752132] lost page write due to I/O error on sda1
[  843.752134] Buffer I/O error on device sda1, logical block 2098547
[  843.752135] lost page write due to I/O error on sda1
[  843.752138] Buffer I/O error on device sda1, logical block 2098548
[  843.752139] lost page write due to I/O error on sda1
[  843.752141] Buffer I/O error on device sda1, logical block 2098549
[  843.752143] lost page write due to I/O error on sda1
[  843.752145] Buffer I/O error on device sda1, logical block 2098550
[  843.752146] lost page write due to I/O error on sda1
[  843.752152] sd 0:0:0:0: >[sda]  
[  843.752153] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  843.752155] sd 0:0:0:0: >[sda]  
[  843.752156] Sense Key : Aborted Command [current] [descriptor]
[  843.752158] Descriptor sense data with sense descriptors (in hex):
[  843.752160]         72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00  
[  843.752167]         01 00 23 10  
[  843.752170] sd 0:0:0:0: >[sda]  
[  843.752172] Add. Sense: No additional sense information
[  843.752174] sd 0:0:0:0: >[sda] CDB:  
[  843.752175] Write(10): 2a 00 01 00 3d 58 00 00 08 00
[  843.752181] end_request: I/O error, dev sda, sector 16792920
[  843.752186] sd 0:0:0:0: >[sda]  
[  843.752187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  843.752189] sd 0:0:0:0: >[sda]  
[  843.752190] Sense Key : Aborted Command [current] [descriptor]
[  843.752193] Descriptor sense data with sense descriptors (in hex):
[  843.752194]         72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00  
[  843.752201]         01 00 23 10  
[...]
[  880.404054] end_request: I/O error, dev sda, sector 4196352
[  880.404058] quiet_error: 41 callbacks suppressed
[  880.404060] Buffer I/O error on device sda1, logical block 524288
[  880.404061] lost page write due to I/O error on sda1
[  880.404068] Buffer I/O error on device sda1, logical block 524289
[  880.404070] lost page write due to I/O error on sda1
[  880.404075] Buffer I/O error on device sda1, logical block 524290
[  880.404076] lost page write due to I/O error on sda1
[  880.404080] Buffer I/O error on device sda1, logical block 524291
[  880.404081] lost page write due to I/O error on sda1
[  880.404084] Buffer I/O error on device sda1, logical block 524292
[  880.404085] lost page write due to I/O error on sda1
[  880.404088] Buffer I/O error on device sda1, logical block 524293
[  880.404090] lost page write due to I/O error on sda1
[  880.404093] Buffer I/O error on device sda1, logical block 524294
[  880.404094] lost page write due to I/O error on sda1
[  880.404097] Buffer I/O error on device sda1, logical block 524295
[  880.404098] lost page write due to I/O error on sda1
[  880.404101] Buffer I/O error on device sda1, logical block 524296
[  880.404103] lost page write due to I/O error on sda1
[  880.404106] Buffer I/O error on device sda1, logical block 524297
[  880.404107] lost page write due to I/O error on sda1
[  880.404129] sd 0:0:0:0: >[sda]  
[  880.404130] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  880.404132] sd 0:0:0:0: >[sda]  
[  880.404133] Sense Key : Aborted Command [current] [descriptor]
[  880.404135] Descriptor sense data with sense descriptors (in hex):
[  880.404136]         72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00  
[  880.404142]         00 c0 08 00  
[  880.404145] sd 0:0:0:0: >[sda]  
[  880.404146] Add. Sense: No additional sense information
 
 
 
Voilà, je tenais à partager ce grand moment de solitude (puis faut bien s'occuper pendant les backup)...

Firmware pas à jour ? Après ~ 5100 heures d'utilisation avec le firmware par défaut, le M4 se fait la malle, non ?

Si, si, firmware à jour. Dans l'absolu, je ne cherche pas un diagnostique; faut juste que je fasse des tests chronophages. Dur, dur quand la motivation n'y est pas
 

Encore ça va, si c'est reproductible en 3 minutes

Finalement, c'est le port SATA sur lequel le SSD système était branché qui agonise.

c'est super rare, si c'est ça c'est vraiment pas de chance

pour ceux qui s'interessent au cache disque par SSD, il y a dm-cache qui a été intégré à linux 3.9

http://linuxfr.org/news/sortie-du-noyau-linux-3-9

Mouai j'ai un peu de mal à voir les cas d'utilisation utiles.

un cache SSD ? pour à peu prêt tout ce qui nécessite une grosse capacité de stockage qui rend difficile l'utilisation d'un SSD unique. Ca permet d'avoir la vitesse du SSD et la capacité de stockage d'un HDD.
(donc ça va du PC fixe perso, aux gros serveurs web, en passant par les NAS)

Heu non: dès que tu vas écrire la capacité du SSD, tu vas faire du cash-trashing et recopier ton SSD dans le HDD. Vitesse globale du bouzin = vitesse du HDD.
Le cas utile c'est si tu utilises tout le temps les mêmes données et donc tu auras un cache-hit proche de 100%. Ce qui veut dire que tu n'utilises que la quantité de données qui tient dans ton SSD.
CQFD il y a peu de cas où se sera vraiment utile.
edit: en contexte pro j'entends.
Sur un laptop/desktop tant que tu utilises toujours les mêmes fichiers et que l'ensemble tient dans le SSD il y aura un gain.

tu dois avoir une application qui fait beaucoup d'écritures constantes et tu as l'impression que c'est pareil pour tout le monde,
certe il y a pas mal d'applications qui nécessitent beaucoup d'écriture (DCRI, transactions financières, mails, archivage, sauvegarde, logs en tout genre) mais ce n'est pas l'immense majorité des applications.    
 
Par exemple la plupart des sites webs, c'est beaucoup plus de lectures que d'écritures, sur des données récentes, pense à HFR, facebook, lemonde.fr, hfr-rehost, kernel.org, github...
 
Et sinon le SSD permet également de gérer une forte augmentation temporaire de l'écriture en faisant tampon en la lissant, après c'est sûr qu'il faut que les algo de cache soient au point pour cela. Le L2ARC sur ZFS commence à être pas mal utilisé par exemple.
 
edit: et je parles de caches avec des SSD avec de vrais capacités (128Go min pour un desktop, 512Go min pour un serveur) pas les merdes avec 8Go, c'est peut-être ça l'incompréhension

Dans l'absolu ça veut rien dire un cache d'écriture de 512Go. J'ai des cas quotidiens où je te le sature en 1 seconde.
Les cas dont tu parles autant mettre le cache en RAM au prix du moment...
512Go de ram pour du cache c'est pas si cher, ça dure plus longtemps et c'est 1000x plus perf

Le problème c'est que la RAM, c'est que c'est 10 fois plus cher que la Flash à capacité équivalente.
Beaucoup de sites webs et serveurs de PME n'ont pas besoin de l'artillerie lourde à plus de 10k€ ou plus (et j'ai l'impression que pour toi c'est même beaucoup plus que ça )
Mais bon de toute façon les cache SSD c'est pas encore au point, mais c'est un domaine actif en terme de R&D chez les grands acteurs comme IBM ou Oracle ou Intel, et c'est un bon point que linux s'y mette aussi.

Il y pas de solution généraliste, une PME ou une grande entreprise qui veut du stockage réactif (déjà réactif est à définir) doit d'abord définir son besoin: IO/s, bande passante, latence, volumétrie, pattern d'io, type de FS (distribué ou pas), etc...
Le SSD pour du cache peut être une solution à pas cher dans certains cas mais le choix est pas toujours évident entre un SSD et quelques barrettes de plus pour se faire un ramfs...
Clairement qu'on y travaille c'est une bonne chose.
 

Tiens, c'est bizarre, je me renseigne actuellement pour mettre un SSD sur un ordinateur avec un nForce4, et quelqu'un m'a répondu qu'il avait un SSD fonctionnant sur un nForcePro 2200.
Lien: http://forum.hardware.fr/hfr/Hardw [...] m#t8704585

- Messagerie
- Grosses DB
- Backup (cache des inodes ce qui accélère les sauvegarde différentielles/incrémentales)
- stockage/GED (les utilisateurs accèdent souvent aux même documents sur une période données)
 
Y a plein de cas où c'est très utile en environnement pro.

Ptain mais tu vois pas plus loin que le bout de ton nez, c'est grave

Oui pas de problème, mettez des SSD en cache d'écriture sur de gros volumes. Tant que vous avez les numéros du support de vos fournisseurs, NP.  
Sur de petits volumes ça fonctionne et encore le ratio perf/prix est plutot en faveur d'un ramfs.
Le bout de mon nez c'est différents contextes: BDD (~2Po sous oracle), HPC, ... et des centaines de SSD morts.

Qui a parlé de cache en écriture ? l'intérêt ici est surtout dans les caches en lecture...

Un cache en lecture sur une grosse BDD ça marche si tu accèdes toujours aux même N Go de données, avec N capacité de ton(tes) SSD(s). Dès que tu sors de N, ton SSD va aller chercher les données dans le support suivant (baies de disques) et donc faire des écritures.
Mettons une BDD de 10To, un cache avec 2 SDD de 512Go, des accès en lecture à 70% random et une charge importante sur la BDD.
Tes SSD font pas long feu (sauf haut de gamme qui chiffres en xxK€, et encore).
Après il y aura des cas où tu fais toujours les mêmes lectures sur un espace qui tiens dans ton SSD. OK.  
A ce moment là autant prendre de la ram qui sera bien plus perf.  

Ben justement, une DB typique en environnement pro, c'est lecture d'un petit set de données sur une période donnée.

Et le cache c'est pas forcément à chaque lecture que tu vas mettre ta donnée dedans, y a la notion de compteurs/temps.

La RAM sera plus performante évidemment mais le prix n'est pas du tout le même, ouvre-les yeux

sauf que au prix de 512Go de RAM, tu as 5To de SSD et là ton cache hit ne sera plus le même

Et à la fin de ta période tu changes les données, donc tu fais des écritures. Plus ta BDD est grande plus tu vas écrire (à ratio lecture/ecriture constant) plus tes SSD vont mourir vite.
Tant que tu fais du cache-hit c'est bon, si tu fais plus de lecture random tu vas changer les données plus fréquemment.
Une DB typique ça veut pas dire grand chose, il y a tous les cas. C'est bien pour ça que je généralise pas et que je dis que bien que la ram coute cher, quand tu fais le calcul perf/prix/longévité/capacité c'est pas toujours en faveur du SSD loin de là.
Encore une fois ça dépend des cas.

Tes 5 To de SSD ils ont une durée de vie directement corrélée à ton cache hit.
Dans le cas où tu vas tout le temps lire la même chose, ok achète des SSD. C'est pas forcément le cas le plus fréquent.

source ?
 
parce que à mon avis il y a bien plus de serveurs pour sites web que de super calculateurs dans le monde, il n'y a qu'à voir les volumes de vente de petits serveur Dell (gamme poweredge)

Ben si

Je parle pas de cluster, je parle de pattern d'io.
Pour avoir travaillé sur de très grosses BDD, c'était relativement random comme accès.
Après dans le web effectivement c'est moins le cas.

Heureusement que tu généralises pas

Vi, mais il a un crucial ... moi, j'ai un OCZ vertex 4 qui ne fonctionne qu'en AHCI apparemment. Son crucial, il a pu le faire marcher en IDE.  
Bref, j'ai en projet un FX8350 sur un 990FX, donc bon, je garde l'OCZ de côté.

Petit retour d'expérience : j'ai installé Xubuntu 13.04 sur mon 840 Pro 256 Go.
 
La différence est tout simplement énorme par rapport à mon DD de 2 To (avec Xubuntu 12.10 dessus)... je boote en quelques secondes seulement.
 
Une fois le TRIM activé (en ajoutant l'option "discard" dans /etc/fstab), 517 Mo/s en lecture séquentielle (sudo hdparm -Tt /dev/sda).

Tu es au double de débit par rapport à mon 840 500Go sous xubuntu 12.10
Tu as quelle config ?

C'est certainement parce que ton disque est bridé par un contrôleur sata2. D'un autre côté, cette différence est imperceptible en usage réel.

hors cas très particuliers:
- transferts de gros fichiers de ssd à ssd
- sauvegarde/restauration de machine virtuelle (vmware, virtualbox)

 
http://forum.hardware.fr/configura [...] o=Calinou_
 
Je suis en SATA 3.
 
Les perfs ont l'air stables, je suis à environ 516 Mo/s après avoir rempli un peu plus le SSD.