mesa-omx-drivers
mesa-vdpau-drivers

Déjà installe ces deux paquets ça ne fera pas de mal.

Sinon regarde la doc sur les ssd disponible dans la rubrique "documentation" du site.
Merci. C'est fait. J'ai merdé et Fedora ne demarre plus.

J'ai suivi le wiki pour ssd http://doc.fedora-fr.org/wiki/Les_SSD_sous_fedora

A la partie 4.3.2… j.ai ouvert le fichier fstab et ajouté "ssd" comme indiqué mais il n'a pas l'air d'apprécier.


J'ai essaye (en root) de modifier fstab avec Vim mais il me dit que le fichier et en lecture seule. Je suis root, je fais ce sue je veux !:hammer:
j.ai ouvert le fichier fstab et ajouté "ssd" comme indiqué
Tu as fait quoi au juste ?
Comme ce qui est indiqué dans le wiki du lien que j'ai posté point 4.3.2 à savoir :
Dans toutes les lignes qui comportent le mot ext4, rajoutez après defaults l'option discard en les séparant par une virgule (et sans espace). Si vous avez des lignes comportant btrfs, rajoutez après defaults les options discard et ssd en les séparant aussi par des virgules (sans espaces non plus).
J'ai essaye (en root) de modifier fstab avec Vim mais il me dit que le fichier et en lecture seule
Essaye ceci avant de lancer vim:
mount -o remount,rw /
Oubli "ssd" dans le fstab, c'est si tu utilise le BTRFS. C'est pourtant indiqué...

L'histoire de la journalisation aussi, normalement les SSD (bon en plus ta un intel) sont quand même résistant de nos jours pour ce genre de chose. En 5 ans mon ancien M400 Crucial n'a toujours pas eu de problème et il tourne toujours d'ailleurs.
Moins on (re)écrit sur un SSD, mieux c'est. Les générations actuelles seraient plus durables. Le minimum, à mon avis:

- pas d'hybernation
- pas de swap (utiliser ou étendre la RAM)
- pas de /tmp (utiliser la RAM, un tmpfs)
- noatime

J'ai vu que noatime pouvait poser problème avec des utilitaires. Et qu'il existe une variante pour ne modifier les statuts des fichiers que une fois par jour.

J'ai pas trouvé d'options simples pour modérer les logs. SE Linux et tout ça, c'est super bavard...

Un Linux qui coince alors que la CPU n'est pas à 100%, je pense en premier à un périphérique qui le bloque. Le disque HS, c'était flagrant, le PC mettait de 30 à 45 min pour finir de booter, et il y avait plein d'erreurs à la console et dans les logs (qui en ajoutait au stress du disque). Il n'y a rien dans le journal pendant que ça coince?
# journalctl -f
-- Logs begin at Thu 2016-02-18 22:10:19 CET. --
Mar 19 19:55:17 ...
Peut être avec iotop? Ou d'autres commandes en rapport avec des entrées/sorties?
# iotop

Total DISK READ :       0.00 B/s | Total DISK WRITE :       0.00 B/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % systemd --switched-root --system --deserialize 21
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
 1027 ...
Sinon, voir avec le pack sysstat... %iowait pourrait être différent de 0?
# dnf install sysstat

# iostat
Linux 4.4.5-300.fc23.x86_64 (***)     03/19/2016      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.99    0.02    0.14    0.04    0.00   98.81

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               2.77        29.40        11.29     365274     140321
sdb               0.24        24.72         0.00     307100         29
dm-0              0.80        13.44         0.37     166993       4632
dm-1              2.37        15.05        10.92     186973     135656
dm-2              0.01         0.17         0.00       2141         32
Après, c'est plus compliqué...
# sar -q
Cannot open /var/log/sa/sa19: No such file or directory
Please check if data collecting is enabled
pidstat pour savoir qui fait quoi avec le disque? Bref, tout ce qui afficherait des stats, des états...
# pidstat -d
Linux 4.4.5-300.fc23.x86_64 (***)     03/19/2016      _x86_64_        (2 CPU)

08:54:06 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
08:54:06 PM     0         1     10.14      0.38      0.00      12  systemd
08:54:06 PM     0        92      0.03      0.00      0.00     215  kworker/u4:3
08:54:06 PM     0       384      0.00      0.12      0.00       8  jbd2/dm-0-8
...
redj12 wrote:Lorsque j'ouvre une fenêtre elle s'affiche en saccadé. Le seul moyen c'est de redémarrer et ça devient insupportable, surtout que c'est sur un SSD. L'utilisation du processeur n'a rien d'anormal.
redj12 wrote:Merci pour votre aide. J'ai désactivé les modules de FF mais rien ne se passe. J'utilisais top pour voir la mémoire utilisé mais en fait, en regardant avec le moniteur de système j'ai trouvé ça :

http://pix.toile-libre.org/upload/thumb/1457378262.png

788 Mo tout de même. (HS: comment on fait pour....
En fait, là dedans, je vois surtout gnome-shell très occupé. 41% de CPU. Pourquoi? ET les 788Mo de RAM, c'est gnome-settings-daemon, pas Firefox...

Les quelques commande, plus haut, permettraient de savoir s'il y a des activités disque élevées, voire des iowait. Mais j'irais d'abord voir les logs (journalctl ou /var/log/messages) s'il n'y figure rien d'anormal.

Peut-être qu'avec les commandes suivantes, il pourrait y avoir des réponses:
journalctl /usr/bin/gnome-shell

journalctl /usr/bin/gnome-session

journalctl /usr/bin/gnome-settings-daemon
D'autres ont eu des problèmes avec leur driver vidéo, ou avec une accélération software plutôt que matériel, ça pourrait aussi expliquer des ralentissements, des lenteurs de l'affichage (qui ne signifie pas lenteur globale du système, ni problème éventuel de disque):

https://www.google.fr/search?q=gnome-shell+high+cpu