Reprise du message précédent :

Ah ben voilà, lu trop vite, pardon.

hello,
 
je vais réinstaller ubuntu 14.04 sur un ssd intel 320 40go.
 
faut-il encore ajouter discard avec cette version car je vois ca sur la doc :
 
je pense que non mais pour avis final..
 
 
""""
 La commande TRIM à la volée est activée par défaut à partir d'Ubuntu 14.04 sur les partitions Ext4 et BTRFS, aucune modification à faire à partir de cette version1).
 
Contrairement à ce qui est souvent dit, tous les SSD sont TRIMé par défaut à partir de 14.04, seul quelques rares SSD ont été blacklistés à cause de bugs de firmware les concernant. (On peut souvent lire que seul les Intel et Samsung ont le TRIM à la volée actif par défaut, ce qui n'était le cas que pour une version de développement d'Ubuntu 14.04, la restriction a été retirée après des tests supplémentaires dans la version finale.)  
""""

Hmmm ça m'intéresse, j'ai un MX100 accompagné d'une Fedora 20, partitions ext4. Dans mon cas, dois-je activer l'option discard ? Je crois que oui mais bon.
De plus, j'ai une autre question, probablement très conne : la swap sur SSD, on la met bien en système de fichiers... swap ?

pour ceux qui cherche un bon SSD pas cher :  
 
Un #BonPlan pour vous donner l'appétit ! Le Crucial MX100 512Go est à 169€ http://clubic.cc/MX100512Go  chez @rueducommerce pic.twitter.com/mNHkSLU3EH
 
J'ai vu ça à midi ... ça vaut le coup je pense

Bonjour à tous,
 
Need une tite confirmation:
 
je vais passer sur un samsung pro 830 256gb sous mint cinnamon.
 
de ce que j'ai lu:
- mettre le /tmp en ramfs ( j'ai 8Go)
- dans sysctl réduire l'utilisation du swap
- noatime sur les partoches dans le fstab
- passer le trim de chaque semaine à chaque jour en déplaçant la tâche cron de weekly à daily
 
correcte ou bullshit?
 
merci

le 830 pro n'existe pas, soit c'est un 830 tout-court, soit c'est un 840 pro

très bonne idée

pas très important sur sdd récent, sauf si tu swap souvent

oui ça c'est recommandé

ou carrément l'option discard si ta charge de travail est lourde et que l'espace libre est faible.
 
je conseillerais aussi de garder un espace vide non partitionné à la fin de quelques GB, tu auras de meilleures performances et moins d'amplification d'écritures.

Bonjour,

-Le /tmp perso je l'ai laissé sur le SSD. Ce n'est pas en temps normal ce qui va le tuer mais pourquoi pas selon les usages
-Réduire l'utilisation du swap, perso je le fais sur toutes les machines, parce que dans mon cas ça ne sert à rien de remplir le swap à partir de 60% de ram libre, en général je descends à 10% (ce qui fait 800mo avec mes configs)
-noatime oui je l'ai fais, si on a pas besoin de la date de dernière lecture c'est toujours ça de gagné pour l'usure du ssd
-le trim perso, j'ai laissé discard, je n'ai pas regardé si depuis que j'ai mis à jour il l'a enlevé ou pas, mais j'ai refais le test pour voir si le trim fonctionnait et ça fonctionnait directement.

Je préfère que la suppression se fasse immédiatement pour le trim et pas à certains moment quand planifié.

sligor: effectivement ^^ et nop il sera pas surchargé je pense, si je le remplit à 50/60% ce sera le maxi
 
merci à vous deux pour les conseils

Je vous rejoins (à nouveau) dès que mon Kingston v300 120Go arrive  

Après être passé au SSHD en disque système, je saute le pas et déplace le SSHD 500 Go en disque 2 et passerai le SSD en disque système  une fois qu'il sera livré

Dans les distros récentes, y'a quelques bricolages a prévoir ou c'est du suivant, suivant pour l'installation?

On peut envisager une partoche chiffrée sur un SSD? Ca ne réduit pas la durée de vie? (l'idéal serait le / sur le ssd et le /home sur le SSHD, tous chiffrés)

Ceci est un re-drapal déguisé

Je ne vois pas pourquoi chiffrer la partition réduirait la durée de vie du ssd...

de ce que j'ai lu, ca empêche le trim sur ces parties

Je ne vois pas pourquoi, enfin ça dépend la manière de chiffrer.
 
Si tu ne chiffres que ce que tu écris, que tu écris 0101010101 ou 1010101010, le ssd s'en fou, tu as écris 10 bits, et il sait quand tu l'effaces etc.  
 
Par contre si effectivement tu remplis avec du "bourrage". Là oui ça pause problème, pour lui tout est occupé en continue.

tu utilises quelle distribution ? le trimming sur partition chiffrée est supporté sur une distrib récente (cryptsetup >=1.4 )
 
Pour l'activer il te faut rajouter l'option allow-discard dans ton fichier /etc/crypttap  
 
http://blog.christophersmart.com/2 [...] ks-on-ssd/

non le problème c'est que c'est le système de fichier qui dit au SSD quel sont les secteurs libérés à trimmer,  
Avec chiffrement il y a un intermédiaire dm-crypt entre le système de fichier et le ssd qui fait le chiffrement. et sans l'option allow-discard il ne va pas forwarder les infos de trim venant du système de fichier vers le SSD...

En fait j'ai abandonné l'idée, l'installateur de kubuntu plante.
 
Sinon, venant d'un SSHD, on voit quand même le gain de performance, c'est bluffant !

Pour que le TRIM fonctionne dans ce cas, y a-t-il obligation à être en LVM ?
Parce-que je comptais découper mon SSD avec Windows en 3 partitions logiques dans ma partition étendue, et les utiliser avec Linux de manière traditionnelle (enfin, si c'est encore possible ).

non LVM n'est pas nécessaire, si tu utilises LVM il faut configurer en plus LVM pour qu'il forward le discard comme indiqué dans l'article, c'est tout

OK
Donc si je comprends bien, je peux reproduire les étapes de l'article en zappant la partie de configuration du lvm

samsun 830 256Gb avec linux mint cinnamon:
 

skoi la commande pour tester ?

hdparm -tTi /dev/sda

C'est le concours de qui qu'à la plus grosse ?
 
J'arrive
 

je passe d'un mecanique 7200rpm avec cluster défectueux à ca, du coup oui ca change ^^

Problème sur le mien ou quoi ?

 
EDIT : après rajout de noatime et discard (mais sans reboot encore, donc... ) :

fait un :
 

Ca me donne ça :

Note : Je suis volontairement en SATA 2, car le 3 est une puce Marvell moins réactive.

bah c'est normal alors le SATA2 te limite les débits séquentiels. Ce n'est pas vraiment grave car dans la vraie vie les accès sont rarement purement séquentiels

Concernant la seconde valeur je suis d'accord, elle correspond au plafond du SATA 2.
Mais que dire de la première (Timing cached reads) ? On se situe tous à plusieurs Go/s Je pensais que c'était un mode qui testait le débit potentiel vraiment max, sans avoir recours au SATA...

ça mesure la vitesse du cache disque de linux qui se situe en RAM.
En gros ça dépend de la vitesse de la ram, de la vitesse du processeur et de la taille de ses caches. C'est pas très important...

Moi aussi ça semble pas fameux
 

 
Et dmesg | grep SATA retourne :

C'est grave docteur ?

partitions alignées? car ta du sata 3

Hm quelle commande pour vérifier ça ?

Idem, ça me semble pas fameux sur ce modèle :

non hdparm fait le test sur le disque de façon "brute", donc le partitionnement ne change rien

my bad alors
 
il est censé sortir combien cd ssd?

Merci pour la précision, du coup je sais également que ça ne provient ni de LVM ni du chiffrement (et pas d'un manque de ram puisque j'en ai 16).  
Donc résultat normal ?

bas en théorie il est vendue avec combien read/write?