Reprise du message précédent :
Extrait de la technical datasheet de Intel :
 
- Sustained Sequential Read: up to 250 MB/s
- Sustained Sequential Write: up to 170 MB/s
 
Merci de t'intéresser à mon problème.

Le SSD est-il neuf ? Si oui, peut être faut-il chercher du contrôleur de ton portable. Es-tu sur qu'il s'agit d'un SATA II ? Si ce n'est pas le cas, les performances du SSD sont plus ou moins normales, puis que en SATA I tu es bridé à 150 Mo/s. Assure toi d'abord de cette information avant de chercher plus loin.

Oui, je suis bien d'accord pour un "problème" matériel, d'ailleurs, je suis sur une piste : j'ai booté avec l'"Intel® SATA Solid-State Drive Firmware Update Tool" qui me dit :

"Your SSD has pre-production firmware"
Mais il ne me propose pas de mise à jour. Quant à l'"Intel® Solid State Drive Toolbox", il s'agit d'un exécutable windows en *.msi, alors qu'il est annoncé comme "OS independant" sur le site. Je ne sais pas quoi en faire.

Je vais continuer ma quête, merci de m'aiguiller quand même.

----- Quelques recherches plus loin -----

Je ne suis pas le seul à avoir ce problème : http://communities.intel.com/message/76277#76277 ; http://forum.notebookreview.com/sh [...] 583&page=2 .

Il semblerait qu'il s'agisse d'une (in)compatibilité entre le contrôleur SATA et le SSD.

----- Quelques énervements et réflexions plus loin -----

Il me paraît clair qu'il s'agit (sur le portable, vu son age) d'un port SATA I. Mais, incapable de trouver l'info (TravelMate 5623 WSMi) pour confirmer. Pas dans le BIOS en tout cas.

Hello,
 
bon, test du kernel 2.6.34 compilé maison.
rajout de l'option "discard" dans /etc/fstab
mode ahci et ordonnanceur CFQ activé.
 

 
résultat hdparm :
 

 
avec corsair P64 64 Go.

A propos du paramètre discard, est-il suffisant pour laisser le kernel s'occuper du recyclage des puces ou faut-il quand même utiliser un wiper ?

 
Les options relatives au filesystem (comme discard et CFQ) n'ont aucune incidence sur les résultats de HDparm, qui mesure le débit que peut soutenir ton périphérique, mais en amont du système de fichiers.
 

Bonjour,
après avoir parcouru votre topic j'ai trouvé de nombreuses informations.
 
pour ma part je possède un OCZ vertex 30 GO en v1.30 qui contient 3 partitions : 1 boot 100 mo / 1 ntfs 20go (win 7) / 1 linux 10go ext4
 
sous windows j'ai souvent constaté des problèmes de performances. je n'ai rarement eu les 180 mo/s annonce en écriture, hdparm me sort 140 mo/s sur le disque en cours d'utilisation.
 après le silence de fonctionnement, les temps d'accès et mon ubuntu qui boot en 8 sec tout plier (20 instances /appli au boot), c'est bonheur .
 
sous linux j'ai pour ma part déplacé mon /home, sur un autre disque dur ce qui me semble vachement plus raisonnable niveau écriture, on à pas besoin de perf sur le home...
 
néanmoins j'ai plusieurs question:
depuis le noyau 2.6 .31 le trim est sensé etre intégré dans le noyau, en fait il ne l'ai vraiment que depuis le 2.6.33 et il n'est pas activé, j'ai donc installé un noyau ubuntu ppa, mais impossible de mettre la main sur l'option dans menuconfig. (sensé etre dans libata)
 
de surcroit le 2.6.33 mon driver Nvidia refuse de se compiler avec DKMS (j'ai installer le header all / header generic et le linux image), c'est un peu obscure pour moi (m-a échoue aussi, histoire de source... pourtant elles sont là...)
 
j'ai découvert donc que le mec qui code hdparm, avait pensé comme moi (font chier ces kernel dev), et il a développé des scripts que l'on peut trouver dans hdparm > 9.27, mais la aussi, impossible de piger comment ca fonctionne. (marche pas chez moi)
 
 --trim-sector-ranges        Tell SSD firmware to discard unneeded data sectors: lba:count ..
 --trim-sector-ranges-stdin  Same as above, but reads lba:count pairs from stdin
 
bref du coup le TRIM sur linux bah... FAIL
je me demandais si le fait que windows 7 integre le trim, il le fait sur tout le disque ou simplement sa partition NTFS (puisqu'il fait appel au firmware pour le faire).
 
sinon je vois pas mal de gens parler de l'option discard dans fstab, mais sans vraiment expliqué ce à quoi cela correspond et la procédure à suivre pour la mise en place (autre que modif du fstab)
 
bref voila pas mal d'interrogation de mon coté, j'aimerais quand même bien foutre ce foutu TRIM en action, ca m'évite de passer par une disquette boot et tralala pour le faire avec wiper.
 
merci par avance de vos réponses

Tu cliques sur le bouton d'édition du message (icône en forme de gomme arrière de crayon) puis en bas dans les options tu coches "Effacer ce message" et ça devrait rouler

 
Tout dépend de l'utilisation qui est faite: il peut y avoir beucoup de trucs dans le home, et parfois des toufus, qui peuvent sérieusement gréver les temps de réponse de la machine
 
Perso mon /home est sur SSD mais tous les trucs lourds (ie occupant beaucoup de place) sont "externalisés" sur des "HDD classiques" avec des liens symboliques

idem, pas beaucoup d'info sur cette option et ses conséquences, trop peu d'infos

Clair que savoir ce que fait exactement discard et comment l'utiliser pour un SSD serait un plus. Pas d'infos, c'est un peu dommage car du coup on ne sait pas si cette option est nécessaire pour le TRIM en temps réel ou pas, tout ça.

Faudrais contacter linus pour en savoir plus qui se lance ?

Je parle pas le finlandais Fais chier.
 
 
Scrout offenstru... Ah non j'suis sote, c'est du suédois
       /

serait cool si je pouvais avoir quelques réponses sur mes questions ceci dit
 
ps : je parle pas finlandais non plus

J'aimerais bien aussi, histoire de compléter les premiers posts...

Un message (en anglais) sur la LKML devrait suffire

 
http://git.kernel.org/?p=linux/ker [...] af;hb=HEAD

Salut à tous,
 
Je viens de refaire ma config avec un SSD Intel, un X25-V. Ce n'est peut-être pas le plus puissant, mais comparé à mon ancien disque dur c'est plus que satisfaisant.    
J'ai installé le / dessus (avec l'option noatime), et sur un Samsung Spinpoint F3, j'ai mis le /var (pour garder les logs quand même), le /tmp, le /home (comme ça je m'emmerde même pas avec le dossier temporaire de firefox, à moins que je me trompe...) et le swap, que j'ai d'ailleurs desactivé. Ca ralentit peut-être un peu ma configuration de mettre quelques fichiers sur le Samsung, mais il ne gratte pas très très souvent.
Globalement c'est très bien : ultra-rapide, silencieux. Et je pense que pour mettre le gros du système c'est nickel.

 
Bonjour,
 
Justement, à ce propos, je me pose une question.
Est-ce qu'on ne perd pas en réactivité en mettant le /home sur un disque dur classique (dossier de conf perso des applis sur le home) ?
 
 
 

Si, je pense que ça doit ralentir un peu, d'où mes réserves.
Mais c'est dur à évaluer quand tout est instantané.
Par contre, des choses qui étaient insupportablement longues sur mon ancien PC sont ébouriffantes, par exemple afficher toutes les icônes quand je modifie le menu; ça se fait immédiatement là où mon ancien PC mettait bien 30 secondes. Pareil l'affichage des gros dossiers (/usr/bin, etc.) sous Thunar est instantané aussi.
Je pense aussi que ça a un impact sur le démarrage, mais comme j'ai desinstallé GDM et mis un autologin, ça joue aussi beaucoup. En gros cinq secondes pour que le bureau s'affiche.  

C'est dommage quand même, tu pourrais avoir un bon gain pour Firefox avec le /home sur le SSD (sur un autre topic on discutait de mettre ça en ramdisk et le gain est impressionnant).
 
Si c'est pour la durée de vie que tu t'inquiètes, à mon avis c'est pour rien : les SSD actuels gèrent sans problème un nombre quotidien d'écritures assez conséquent. (les données constructeurs en terme de longévité sont calculées à partir d'un chiffre genre 20Go/jour, tu en seras très loin avec ton /home )

Eh bien, je viens de trouver une solution intermédiaire en mettant le cache de firefox sur un tmpfs. Je trouve l'idée d'un script pour synchroniser le cache au démarrage et à l'extinction un peu lourd pour si peu, et le cache sur le tmpfs est un bon milieu, car si la page du forum hardware met un peu plus de temps la première fois que je la charge, ça va beaucoup plus vite ensuite.  

Oui mais ce qui est très lourd sur Firefox c'est sa BDD sqlite, qui n'est pas comprise dans le cache, on gagne beaucoup à mettre tout le répertoire Firefox en ram
(parce que si ça n'est que mettre le cache en ram, autant désactiver le cache disque dans FF et augmenter le cache RAM, ça n'a pas vraiment de sens d'utiliser le cache disque pour le mettre en ram puis le perdre au reboot)

Ah d'accord, je ne savais pas tout cela. Sur mon dinosaure j'avais plutôt l'habitude d'utiliser Midori qui était d'ailleurs très performant.
Je vais essayer la méthode du .mozilla dans un tempfs avec une sauvegarde sur le disque dur à l'extinction, comme précisé dans la première page alors.  

Oui j'avais complètement oublié que c'était ici-même qu'on avait parlé du .mozilla en tmpfs

Dites c'est normal que je n'ai pas les memes resultats avec hdparm sur sda1 qui est le root et sda2 qui est le home??
pareil pour le script de la page 6
 
c'est a cause que ce soit la partition d'install de l'OS je pense non??

Je viens d'appliquer à Chromium la manip du tmpfs.
(pour mon netbook avec son SSD ultra-lent, ça permet de ne pas être ralenti par ses performances en écriture)
 
Donc un simple lien symbolique de ~/.cache/chromium vers /tmp/chromium (mon /tmp étant monté en tmpfs et le dossier /tmp/chromium créé à chaque démarrage)
Ainsi qu'un montage en tmpfs de ~/.config/chromium, et rsync au démarrage et au shutdown avec ~/.config/chromium_ref
 
C'est top, plus aucun accès au SSD en navigation web, et sur cette machine, ça se sent  

En parlant de ca, j'aimerais bien faire ca proprement pour Firefox. Quelle est la meilleure manière de faire ca ? On évite l'usine à gaz et j'ai pas envie d'un truc avec des chemins codés en dur de partout. Je préférais avoir une solution multi-utilisateurs.  
 
Je voulais faire un truc comme ca :  
- monter /tmp/firefox en tmpfs via le fstab,
- à l'ouverture de la session d'un utilisateur, monter le profile firefox dans /tmp/utilisateur-firefox. Cela implique que j'accorde à mes utilisateurs le droit de monter leurs profils firefox en tmpfs grâce à sudo.
- un petit rsync pour copier le profil dans le tmpfs,
- des sauvegardes via crontab du profil de l'utilisateur,
- sauvegarde du profil et démontage du profil à la fermeture de la session, ou quelque chose de similaire.
 
Ca vous semble correct ? Vous avez mieux à me proposer ?  
 
Merci d'avance.

Hello,
 
voici un texte copier ds un magasine linux à propos du noyau 2.6.33.
 
TRIM, Libata et couche IDE
Les supports de stockage tels que clés USB et SSD se composent de «cellules » qui ne supportent qu'un nombre limité d'écritures. L'astuce permettant d'offrir à ces périphériques une durée de vie correcte est la présence d'un contrôleur intégré, qui se charge de répartir les écritures de manière à ce que certains blocs ne s'usent pas prématurément. Cette technique est connue sous le nom de wear-leveling. Pour qu'elle fonctionne convenablement, il faut que le contrôleur puisse disposer du plus grand nombre de blocs libres possible, sur lesquels il pourra répartir les opérations d'écriture.
Maintenant, imaginons la situation suivante : on crée un fichier, on le remplit de données, on l'efface. Pour simplifier grossièrement, un système de fichiers typique va matérialiser ce fichier en créant une structure, un peu comme un index, contenant entre autres le nom du fichier (et diverses métadonnées), réserver des blocs disque et y inscrire les données, puis inscrire dans la structure / l'index que ces blocs correspondent aux données. Lors de l'effacement, la structure sera réinitialisée et ne sera plus associée aux blocs de données. Mais ces blocs continueront à contenir des données... Le système de fichiers se contentera de noter qu'ils sont à nouveau libres pour en recevoir de nouvelles.
Au final, on comprend facilement que sur un système de fichiers, on aura toujours, parmi l'espace qu'il considère libre, des blocs contenant des données anciennes. Le problème est que le contrôleur, lui, ne sera jamais au courant que ces blocs sont à nouveau libres. Une commande spécifique nommée TRIM a donc été créée à cet effet : elle permet de signaler au contrôleur du périphérique de stockage des blocs qu'il peut considérer comme à nouveau disponibles. Ce serait trop beau si l'histoire s'arrêtait là... La spécification indique que cette commande ne peut pas être mise en queue comme les autres commandes. Concrètement, cela signifie qu'il faut attendre la fin d'une série de requêtes, envoyer la commande TRIM et attendre qu'elle se soit exécutée pour reprendre les requêtes classiques. De plus, cette commande est tellement mal implémentée par le peu de matériels qui la prennent en charge qu'elle met souvent plusieurs centaines de millisecondes à s'exécuter. On comprendra donc qu'elle est à utiliser avec précaution. Néanmoins, le noyau 2.6.33 est le premier à l'implémenter au sein de la Libata, couche d'accès aux périphériques IDE, SATA, . ., Actuellement, les FS suivants sont compatibles : Ext4 et FAT, et Btrfs (depuis Linux 2.6.32). Pour activer cette fonctionnalité, il faudra indiquer l'option discard au montage.
 
Copier ici
 
 
 

 
En plus de mon barefoot transcend, je viens de commander un runcore 32go pour remplacer le 16go pourri de mon eeePC. Je vous tiendrais au courant

L'ordonnanceur fonctionne au niveau block, pas au niveau du fs.  
Perso, j'utilise deadline: presque pas de réorganisation et d'attente, mais quand-même un peu de prio pour la lecture.
 
Pour le discard/trim, j'attends que vous essuyez un peu les plâtres avant de tester

En parlant du discard, si on balance un secure erase, ca le déclenche ?

 
Au temps pour moi  

Bonjour à tous
 
je viens de commander ça :
http://www.crucial.com/eu/store/pa [...] 256MAG-1G1
donc j'aurai bientôt besoin de votre aide pour tout faire dans les règles !
(Pour tout dire, malgré que j'ai lu les dernières pages, j'ai du mal à voir clairement les choses pour le trim / script wiper ...)

Après quelques péripéties le disque est bien arrivé. Au boulot maintenant !

ça commence pas top   on va dire qu'il est trop récent !
Après quelques recherches, la réponse étant finalement dans le topic (qu'est-ce qu'il est bien ce tomik     ) :

Ca ira mieux !

Ensuite, je suis le tableau magique et je commence à créer les partitions mais je reçois ces messages

Donc après un bon moment d'essai, des créations de partitions par secteur et d'autres en Gb (puisqu'en fait parted aligne tout seul) et vu que j'ai déjà 63 secteurs mangés par je ne sais quoi :

Voilà
Est-ce que ça vous parait correct ?

Le MBR est toujours sur le premier secteur d'un disque (première piste), et vu qu'une partition commence toujours au début d'une piste, elle ne peut commencer qu'à la piste suivante soit 63 secteurs plus loin

ok
c'est juste que dans le post de Kortex, il part bien de 0.
merci
 
tant que j'y suis : sur mon kernel 32 bits, pas possible d'avoir plus que 3 Go de ram, vous confirmez ?

Non, 4 Go en 32 bits. La limite de 3 Go c'est sous fenêtre pour d'obscure raison qui n'appartiennent qu'à petit mou.

Mmmh il y a aussi des BIOS qui se réservent des pans entiers de l'espace dispo en 32 bits, ça revient assez régulièrement sur le forum.
Dans de rares cas une mise à jour du BIOS peut corriger le soucis, la meilleure solution étant de passer en 64 bits.

bin le bios voit bien les 4 Go
mais ni linux ni fenetre comme tu dis kortex
   
vivement que la slack 13.1 sortent
 
edit : je viens de tester vite fait un kernel 64 à l'arrache dans mon système 32 et là je vois bien 4 Go
"ouf" ([my_life]'fin va falloir que je passe à la slack 64 alors que j'avais pas prévu [/my_life])
 
merci
 
sinon, mes alignements ?

T'emmerde pas, passe sous Arch x86_64