Reprise du message précédent :

Si t'as du stock fait tourner

[edit pour en dessous] En fait j'ai vu la bête, c'est une clef usb/esata, bof

Disons qu'un pote change régulièrement de config et revend du matos qui à trois mois au tier-prix
Mais, généralement, sa part vite, à 10 min près, je l'avais pas le ssd...

wat ?
http://www.prixdunet.com/composant [...] gb-mlc.htm

Ah oui, m'a planté de nom du constructeur, mais bon, j'ai des doutes avec les ssd du genre là (pas de trim ? freezes dû au contrôleur en mousse...)

Salut les amis, je viens tout juste de commander un SSD. J'ai fais quelques recherches sur google et il semblerait que certaines personnes utiliseraient EXT4 sans la journalisation (en gros un ext2 amélioré quoi).
 
Ça vous parait une bonne idée ?  
 
Sinon, quid du swap/var/tmp ?

Pour ext4 ou 3 d'ailleurs sans atime (option noatime dans fstab), c'est ce que je fais moi même. Après, comme l'a dit Dek plus tôt, pas de journalisation du tout, en cas de crash (ou plutôt de coupure de courant puisque Linux ne crash jamais ), c'est moche. On garde donc la journalisation des écritures, mais pas celle des lectures. C'est un bon équilibre, et puis avec les algo de wear-levelling, ça roule.
Dans mon cas, 2 Go de RAM, pas de swap, tmp en tmpfs, et var j'y ai pas touché sauf le cache de mon gestionnaire de paquets, également en tmpfs.

ouaip, justement, je pensais plus  au problème des coupures de courant... qui pourrait être pallié avec un onduleur.
 
Ok, j'vais donc regarder de ce côté là. Pour le Swap, ça devrait pas être un souci (4Go de RAM). Au pire, on pourrait imaginer passer le /var et /tmp sur un HDD ?

C'est le genre de question que je ne me suis pas posé, parce que je tourne avec un portable, donc un seul disque. Par contre, pour tout ce qui est système pur, dont /tmp fait partie, je pense qu'il faut que ce soit soit sur le SSD soit sur le tmpfs, sinon tu perds un peu l'intérêt des débits du SSD (placer sur un système lent ce qui bouge le plus, c'est un peu dommage non ? ).
Et pour ce qui est de l'onduleur, oui, ça corrige les problème d'alimentation, mais plus sérieusement, on est jamais à l'abros d'une fausse manip ou d'un crash inopiné. Même si c'est rare, sans journalisation, ça peut avoir des conséquence, d'où l'équilibre trouvé entre l'arrêt de la journalisation en lecture pour économiser le SSD, mais la conservation de la journalisation en écriture.

drapal

 
C'est ca le noatime?
Je suis en EXT4
 

Exactement

Lecture du jour, SSD et btrfs: http://www.phoronix.com/scan.php?p [...] mode&num=1

C'est pas très encourageant pour Btrfs sur SSD. A première vue, ext3/ext4 restent encore un choix plus judicieux non ?

btrfs n'est pas encore stable (même loin de l'être quand on voit que ext4 ne l'ai pas complètement).

Je sais, c'est ne plein développement. En parlant de ext4 d'ailleurs, à force de lire des choses de ci de là au sujet de ce FS, notamment rapport à sa stabilité parfois douteuse (même si globalement le FS est stable), je me demande si je n'aurai pas mieux fait de monter mon SSD en ext3, toujours avec noatime. Même si ext4 est globalement stable, quand il s'agit d'un FS, on demande une stabilité irréprochable, les conséquences étant potentiellement trop lourdes en cas de problème.  C'est pas un lecteur multimédia quoi

ext4 est stable, c'est juste que certaines présomptions qui étaient vraies la plupart du temps à ext3 ne le sont plus avec ext4 (notons qu'elles ne l'ont jamais été avec xfs par ex).

drapal : exelente initiative, merci
mon feedback bientot ; ocz solid series avec  controleur en mousse, pas de freeze a priori sauf firefox, isolé.
je vais donc appliquer ce qui a été dit plus haut et je vous tiens aware

avis aux spécialistes : que vaut le reiserfs pour un SSD ?
 
Habitué à ce FS, toujours robuste chez moi (ce qui n'a pas toujours été le cas pour ext3), je n'aurai pas trop envie d'en changer le moment venu...  
 
Merci pour vos commentaires pertinents !

Huhu  
 
Drapal

Dites les gens, régulièrement, ( 3, 4 fois par jours ) mon ssd silicon power 32 Go freeze...
Quand je dis freeze, c'est erreurs I/O dans la console, plus rien sur le disque n'est accessible etc...
( Ah pis ma diode HDD reste déserpérement allumée... )
Infos complémentaires pour les gourous :  
kernel 2.6.26-2-amd64, le ssd est en reiserfs avec notail,noatime.
Vala, si quelqu'un à une idée
Par contre, 15 secondes pour démarrer, que du bonheur...

Ce serait pas un contrôleur JMicron sur ton SSD ? Si oui, normal, ça vient de ce contrôleur de merde qui perd les pédales par moment.

Le truc c'est que j'ai pas réussis à trouver d'infos ni sur le controleur, ni sur les puces de ram...

Je vois difficilement comment les puces pourraient être responsable. En revanche le contrôleur...

Surchauffe qui provoquerai une série de réécriture par le controleur...
Mais la piste du controleur est celle a suivre, si je trouve de la doc dessus...

http://www.hardware.fr/articles/73 [...] alent.html
Si c'est bien ce SSD que tu as, alors pas de bol :

Et merde...
Pas de solution ? brider la vitesse pitète ?
Ou alors, je greffe un rad sur le controleur, il m'a juste un pue l'air de chauffer...

Le JMicron freeze en utilisation intensive... Il freeze pas de lui même par magie

Intensive ?
J'ai tout en ram....
Ya pas une commande permettant de savoir quels sont les fichiers auxquels accède une application X ou Y ? ( genre lsof mais en plus ciblé... )

 
j'envisage de me choper un intel x-25E (SLC donc).
 
J'ai cherché des tests de baisse de perf sous linux mais je n'ai rien trouvé Est-ce qu'avec les algos de wear leveling c'est vraiment mieux d'avoir un SLC sous linux ?
 
merci

Etant sous Arch, j'ai installé le noyau 2.6.30 depuis le dépôt testing. Dans cette version, le TRIM est sensé être supporté définitivement, c'est en tout cas les informations que j'avais eu, mais je ne vois rien dans le changelog. Je vais essayer de trouver des infos claires et précises à ce sujet, mais ce serait une excellente nouvelle pour les utilisateurs de SSD à base de contrôleur Indilynx (OCZ Vertex, SuperTalent ME, G.Skill Falcon). Et en avance nativement sur Windows en plus, la classe, reste plus qu'à confirmer l'info.

Le 2.6.30 apporte quelques changements pour ext4, qui ne devrait plus subir les fichiers à 0 octets

Prochaine installation en ext4 \o/ euh... wait debian... /o\

Bon, TRIM semble bel et bien supporté dans la version 2.6.30 \o/
 
http://www.kernel.org/pub/linux/ke [...] Log-2.6.30

Kortex : es-tu certain qu'ajouter l'infrastructure = prise en charge du TRIM ?
 
NB : je n'ai pas de SSD, c'est juste une réflexion pour toi...

Je ne sais pas, mais les dernières infos que j'avais eu étaient que le kernel 2.6.29 pouvait déjà supporter le TRIM si il était patché, et que ces patchs devaient être intégré à la version 2.6.30. Le changelog semble le confirmer, mais après, je n'ai pas de certitude, et aucun moyen de le vériffier ni de savoir ce que ça va réellement changer en pratique en dehors du discours marketing de Indilynx.

C'est bien là où je voulais en venir... on sait qu'il y a des trucs, mais on ne sait pas si c'est effectif...
Si tu as un dual boot, tu peux éventuellement lancer un des tests de SSD pour voir si les perfs baissent sur la durée (à condition de n'utiliser pratiquement QUE linux aussi... ).

btrfs gagne un mode SSD :
http://kerneltrap.org/mailarchive/ [...] id-5943443

Bonjour tout le monde
Je suis entrain de travailler sur les flash nand,et j'ai une flash nand Samsung
Voici la data sheet sur ce lien :
http://www.samsung.com/global/syst [...] _rev10.pdf

En fait je cherche à savoir comment je peux appliquer le wear leveling sur cette flash.
J'ai aucune idée pour les algoritmes du wear leveling,comment ca marche.
J'espère qu'il y aura quelq'un qui puisse m'aider.
Merci pour vos réponses
wassim

Merci pour le tuto ! Je viens d'installer un Vertex 120 et par dessus une arch linux 64 en ext4 en suivant les explications.Pas d'environnement graphique pour l'instant, je paufine encore un peu mon rc.conf.Pour l'instant tout a l'air de rouler.

Merci pour les encouragements

2 questions afin de comprendre un peu mieux cette histoire d'alignement
 
1) Dans ce tuto :http://www.ocztechnologyforum.com/ [...] stcount=98
l'auteur dit :

Est-ce vraiment plus intéressant en perfs, ou durée de vie que 128KB pour l'alignement ?
 
 
2) Comment s'y prendre pour aligner une partition étendue ?

Ok, donc si ce sont les partitions logiques qui doivent être alignées, il faut aligner la 1ère part logique au prochain bloc après le début de la partition étendue, c'est bien ça ? mais comment savoir quelle place prend le début de la partition étendue ?
Est ce que quelqu'un a testé tout ça ?
 
 

1°/ Je ne sais pas trop, Albator le disait lui même, on est parti sur une taille de bloc de 128 Ko par principe, sans vraiment savoir quelle était réellement la taille de ces blocs, mais en déduisant logiquement que ça devait être de cet ordre là. S'il est confirmé que la taille de bloc est en fait de 512 Ko, il suffit de modifier la formule de manière à prendre cette données en compte et réaligner dessus. Après, je ne sais pas trop comment avoir une certitude de la taille des blocs d'un SSD. Il est possible que ça change d'un disque à l'autre.
 
2°/ Oui, il faut créer ta partition étendue, puis aligner au sein de cette partition étendue les partitions logiques comme on le fait avec des partitions primaires. Le principal est que, primaires ou pas, le début de chaque partition doit être un multiple de tes blocs pour rester alignée.