Reprise du message précédent :

Bienvenue parmi nous, petit ours
 
C'est clair que le SSD, ça donne un sacré coup de fouet au système.

Cai Grumly le petit ours, pas krumli

Validé! Rien à voir

hdparm 9.26 vient de tomber dans ArchLinux. Le script wiper devrait donc être utilisable Je vais faire un test (j'ai peur vive la sauvegarde d'hier soir) et je vous tient au courant.

Edit :
J'en ai profité pour passer sur la version 2.4 du wiper, mis à jour hier. Voila le run à blanc :

On voit bien qu'il trouver une plage à trimer.

Voila le run avec commit :

Ca ne fonctionne donc pas, suite à une erreur d'entrée/sortie, mais on en sait pas grand chose de plus... Je vais essayer de comprendre ce qui déconne, mais j'ai peur que ça dépasse rapidement mes capacités...

Le tout sur un Vertex FW1.30

Problème rapporté sur le site d'OCZ :
http://www.ocztechnologyforum.com/ [...] post430740

Bon, je m'auto répond : il faut le firmware 1.4b avant de pouvoir utiliser le wiper Il y a toujours quelque chose qui ne va pas Et vu les problèmes que rencontrent Indilinx et OCZ pour fiabiliser le nouveau FW, notamment au niveau de l'équilibre du garbage collector, c'est pas forcément pour tout de suite la version finale.

Essaye de vérifier l'impact (avant et après donc) du trim avec hdparm/boot/io...

Non, mais pour l'instant ça marche pas (à cause du FW 1.30), et je ne veux pas flasher mon SSD avec un FW beta, donc mise en attente du script jusqu'à la sortie du prochain FW officiel chez OCZ.

Bonjour à tous.
 
Comme je vais bientôt recevoir un ssd, j'ai lu tous vos messages depuis la page 1.
 
Au sujet de l'alignement sur 128 ou 512ko, et comme il n'y a pas de pièces en mouvement en SSD, je suis perplexe, mais pourquoi pas et comme la place perdue est infime...
 
Au sujet des logs, j'en ai actuellement une quarantaine sous visionneur de journaux système. c'est un seul "démon" qui les coupe tous ?
Comment monter /var/log en tmpfs ?
 
J'ai un système sur Hd classique, et compte utilise clonezilla pour y transférer mon Linux ubuntu à jour.
J'ai déjà utilisé Clonezilla sur des Hd classiques.
S'il y a une précaution particulière avec un SSD  et CloneZilla...
A moins que vous pensiez qu'il vaut mieux réinstaller un système complet, et le mettre à jour ?
 
Comme je sature de temps en temps ma ram (8 go) avec Blender, malgré les optimisations des couches et meshes ( 3D sur un site de 26 Ha, ca bouffe de la Ram ... et du temps à modéliser), je garderai ma partition swap actuelle.
Idem pour mes données audio et vidéo. mais je me ferai aussi une partition de données sur le SSD.
 
Dans 10 jours, je vous dirai ce que je pense des SSD.

Ubuntu 9.10 boot optimizations: 5 second startup with an SSD
je me lève et je confirme
impressionnant !

J'ai installé 1 SSD sur chacun de mes 2 PC.
Si je monte le répertoire /temp en Ram (Tmpfs), certaines choses ne marchent pas ! (exemple: essayez de télécharger les templates de QdvdAuthor: ils se téléchargent mais ne s'installent pas !)
 
Silencieux, entre 2 et 3 fois plus rapide que mes HD classiques selon l'usage.
Je verrai bien si les performances baissent avec le temps !

Toujours au sujet du dossier temp: pas de normalisation du son sur projet cd audio si monté en tmpfs
Pas de souci si temp à la racine du disque.
Mon Os: ubuntu 9.04, car j'utilise 8 Go de ram.
Tiens, j'ai lu que Seven de microsoft n'est pas compatible à 100 % en version 64 bits, par exemple, pas de flash player adobe.
Xp est moins accéléré par le SSD que mon linux.
Probablement du au système de fichiers ext4 que microsoft ne connait pas... et que mon Xp est en 16 bits...

Pb de tmpfs résolu en relisant les 7 pages de ce sujet:
 
# none /tmp tmpfs defaults,nosuid,nodev,noexec 0 0  # noexec ne permet pas l'exécution depuis le tmpfs
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0    # ca, ca marche bien, je normalise, installe...
 

Ton XP est en 16 bits OO
Mais fait nous une copie, vite, c'est extraordinaire !!!!
Non, tu voulais dire 32...

 
Oui, 32 bits, désolé, je ne l'utilise plus depuis plus d'un an. Je viens de récupérer sa partition pour mes données: adieu définitif à Microsoft.
 
Ce qui est important, c'est de constater que le SSD profite plus à Linux qu'à Windows

le nouveau slc ocz arrive
 
il poutre le mlc intel en 34 nm niveau perf

 
source ?

Sinon, le SSD pourri de mon Acer Aspire One (pour rappel, perfs décentes en lecture mais anémiques en écriture) n'a jamais aussi bien fonctionné que maintenant qu'il est en Ext2/noatime    
Et tant pis pour la journalisation, ça le fait trop ramer.

 
http://www.driverheaven.net/reviews.php?reviewid=844

 
Ptin le site pourri niveau design
 
Bon ce que j'en lis d'un coup d'œil c'est que c'est plus perfs mais plus cher aussi (enfin si on compare au 80Gio Postville).
 
Je pense que j'ai pas fait une bétise avec la commande du Postville qui devrait arriver ce soir ou demain chez moi
 
Merci pour la source

ah ba oui évidemment le postville est en MLC
 
mais le intel slc est plus cher que ce ocz

 
ouais enfin du MLC qui dépote bien quand même

Holy fucking shit !  
Je viens d'installer Karmic en ext4, temps de boot chrono en appuyant sur entrée dans le menu GRUB :
- 9.6 secondes pour arriver à l'écran de Log in
- 1.4 secondes pour avoir une session pleinement ouverte
 

 
Ce petit postville démonte bien
 
Bon faut que je fasse le tmp en ram et noatime !

video

why not. Je check si j'ai quelque chose sous la main pour prendre une vidz !

ça y est j'ai eu le temps de reboot et de filmer (lol).
Je vois comment extraire et compresser le bouzin.

edit : ptin mais ça change tout bordel, le multiboot sera nettement moins douloureux en cas de jeux !

un petit coup dans handbrake si besoin.

En cours d'upload (mencoder en CLI ça va très bien).
Si vous avez mieux que tinypic pour host la vidéo, je suis preneur.

http://tinypic.com/player.php?v=2a69ffl&s=4

edit : à noter le message d'erreur sur l'USB que j'ai pas eu au boot d'avant, a voir pourquoi ça fait ça, ça doit me ralentir encore

 
Rien d'exceptionnel, je fais le même temps sous Arch avec un Vertex

Bon, bah le bootchart associé donne quoi pour le postville ?

faudrait que je retrouve ma source, mais le noatime n'est pas une optimisation vraiment nécessaire en ext4

Ben apparemment ça limite quand même pas mal les accès écriture au SSD, donc ça doit influer quand même non ?

 
Il me semble au contraire que c'est une optimisation universelle (y a même un équivalent sous windows ...) et que le bénéfice apporté par ce paramétrage rend toutes les autres optimisations négligeables ... autrement dit, il n'y a aucun cas de figure où on devrait utiliser autre chose que "noatime".

Hmmm je n'irais pas jusque là, certains programment chouinent avec noatime : mutt par exemple (c'est ce que j'ai lu, ça n'est peut-être plus vrai, et je ne l'utilise pas).
 
Néanmoins j'ai du noatime partout et aucun problème, en effet  

Le noatime est un paramètre qui pose problème dans des cas extrêmement spécifiques, puisque le date de dernière lecture ne va être utilisé que très rarement, contrairement à la date de dernière écriture. Que fait mutt pour râler contre noatime ?

Je ne fais que répéter bêtement ce que j'ai lu, je n'en sais pas plus    
 
Même si ça ne pose pas de problème 99% du temps, je pense qu'il est quand même bon  de savoir que cette option n'est pas neutre (alors que relatime l'est totalement de ce point de vue).

Dans mes souvenirs, le noatime ne permettait pas de gagner grand chose grâce aux derniers kernel 2.6.29 à 2.6.31
Désolé je retrouve plus le lien, ma mémoire me trahirait-elle ?

A savoir que c'est pas trop en perf mais plus en durée de vie du SSD qu'on économise grâce à noatime aussi, quand tu parles de gagner quelque chose, c'est dans quel domaine ?

Je pense qu'il parle de perf, en effet les fs ext* sont par défaut montés en relatime maintenant, qui diffère l'écriture des atime et donc améliore les perfs.  
Mais si on a pas besoin des atime, noatime fera toujours moins d'écriture sur le ssd

en tout cas c'est vraiment chouette la réactivité du SSD
Je vais passer mon dossier firefox en ram, histoire de pas écrire trop de trucs, vu que j'ai 4Gio de ram, ça risque pas de poser souci !

 
Justement si, je me rappelle de benchs qui montraient de bons gros gains, même sur Ext4 et kernels récents, par contre les gains avec relatime étaient beaucoup plus modérés.