== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours_and_Msec 0x0032   100   100   000    Old_age   Always       -       88h+58m+56.440s
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       105
170 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
174 Unexpect_Power_Loss_Ct  0x0032   100   100   000    Old_age   Always       -       6
183 SATA_Downshift_Count    0x0032   100   100   000    Old_age   Always       -       74
184 End-to-End_Error        0x0033   100   100   090    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   024   047   000    Old_age   Always       -       24 (Min/Max 16/47)
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       6
199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always       -       0
225 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       4177
226 Workld_Media_Wear_Indic 0x0032   100   100   000    Old_age   Always       -       65535
227 Workld_Host_Reads_Perc  0x0032   100   100   000    Old_age   Always       -       52
228 Workload_Minutes        0x0032   100   100   000    Old_age   Always       -       65535
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   100   100   000    Old_age   Always       -       0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       4177
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   Always       -       3978
249 NAND_Writes_1GiB        0x0032   100   100   000    Old_age   Always       -       234
Comment suggéré plus haut, j'ai réinitialisé les paramètres de Firefox mais cella ne change rien. Il m'arrive encore de temps à autre d'avoir ces lenteurs. Je reboot dans ce cas là.
Bon ton SSD est sain.
Au passage on peut en apprendre un peu plus sur ta machine?

Est ce que tu as suivi la doc sur les SSD?

Que retourne : 
dnf list mesa*
glxgear (la laisse pas tourner longtemps)
Alors, pour la machine j'ai un portable Toshiba C50-A-153 tout pourri mais qui tourne bien normalement.
Sinon, pour le SSD je n'ai pas du tout regardé la natice. Je me suis dit que je n'avais rien à apprendre hoho

Voici le retour de la commande :
[red@localhost ~]$ dnf list mesa*
Last metadata expiration check: 13 days, 0:59:30 ago on Sun Mar  6 11:42:04 2016.
Paquets installés
mesa-dri-drivers.x86_64              11.1.0-2.20151218.fc23     @updates        
mesa-filesystem.x86_64               11.1.0-2.20151218.fc23     @updates        
mesa-libEGL.x86_64                   11.1.0-2.20151218.fc23     @updates        
mesa-libGL.x86_64                    11.1.0-2.20151218.fc23     @updates        
mesa-libGLES.x86_64                  11.1.0-2.20151218.fc23     @updates        
mesa-libGLU.x86_64                   9.0.0-9.fc23               @koji-override-0
mesa-libgbm.x86_64                   11.1.0-2.20151218.fc23     @updates        
mesa-libglapi.x86_64                 11.1.0-2.20151218.fc23     @updates        
mesa-libwayland-egl.x86_64           11.1.0-2.20151218.fc23     @updates        
mesa-libxatracker.x86_64             11.1.0-2.20151218.fc23     @updates        
Paquets disponibles
mesa-demos.x86_64                    8.2.0-4.fc23               fedora          
mesa-dri-drivers.i686                11.1.0-2.20151218.fc23     updates         
mesa-filesystem.i686                 11.1.0-2.20151218.fc23     updates         
mesa-libEGL.i686                     11.1.0-2.20151218.fc23     updates         
mesa-libEGL-devel.i686               11.1.0-2.20151218.fc23     updates         
mesa-libEGL-devel.x86_64             11.1.0-2.20151218.fc23     updates         
mesa-libGL.i686                      11.1.0-2.20151218.fc23     updates         
mesa-libGL-devel.i686                11.1.0-2.20151218.fc23     updates         
mesa-libGL-devel.x86_64              11.1.0-2.20151218.fc23     updates         
mesa-libGLES.i686                    11.1.0-2.20151218.fc23     updates         
mesa-libGLES-devel.i686              11.1.0-2.20151218.fc23     updates         
mesa-libGLES-devel.x86_64            11.1.0-2.20151218.fc23     updates         
mesa-libGLU.i686                     9.0.0-9.fc23               fedora          
mesa-libGLU-devel.i686               9.0.0-9.fc23               fedora          
mesa-libGLU-devel.x86_64             9.0.0-9.fc23               fedora          
mesa-libGLw.i686                     8.0.0-7.fc23               updates         
mesa-libGLw.x86_64                   8.0.0-7.fc23               updates         
mesa-libGLw-devel.i686               8.0.0-7.fc23               updates         
mesa-libGLw-devel.x86_64             8.0.0-7.fc23               updates         
mesa-libOSMesa.i686                  11.1.0-2.20151218.fc23     updates         
mesa-libOSMesa.x86_64                11.1.0-2.20151218.fc23     updates         
mesa-libOSMesa-devel.i686            11.1.0-2.20151218.fc23     updates         
mesa-libOSMesa-devel.x86_64          11.1.0-2.20151218.fc23     updates         
mesa-libOpenCL.i686                  11.1.0-2.20151218.fc23     updates         
mesa-libOpenCL.x86_64                11.1.0-2.20151218.fc23     updates         
mesa-libOpenCL-devel.i686            11.1.0-2.20151218.fc23     updates         
mesa-libOpenCL-devel.x86_64          11.1.0-2.20151218.fc23     updates         
mesa-libd3d.i686                     11.1.0-2.20151218.fc23     updates         
mesa-libd3d.x86_64                   11.1.0-2.20151218.fc23     updates         
mesa-libd3d-devel.i686               11.1.0-2.20151218.fc23     updates         
mesa-libd3d-devel.x86_64             11.1.0-2.20151218.fc23     updates         
mesa-libgbm.i686                     11.1.0-2.20151218.fc23     updates         
mesa-libgbm-devel.i686               11.1.0-2.20151218.fc23     updates         
mesa-libgbm-devel.x86_64             11.1.0-2.20151218.fc23     updates         
mesa-libglapi.i686                   11.1.0-2.20151218.fc23     updates         
mesa-libwayland-egl.i686             11.1.0-2.20151218.fc23     updates         
mesa-libwayland-egl-devel.i686       11.1.0-2.20151218.fc23     updates         
mesa-libwayland-egl-devel.x86_64     11.1.0-2.20151218.fc23     updates         
mesa-libxatracker.i686               11.1.0-2.20151218.fc23     updates         
mesa-libxatracker-devel.i686         11.1.0-2.20151218.fc23     updates         
mesa-libxatracker-devel.x86_64       11.1.0-2.20151218.fc23     updates         
mesa-omx-drivers.x86_64              11.1.0-2.20151218.fc23     updates         
mesa-vdpau-drivers.i686              11.1.0-2.20151218.fc23     updates         
mesa-vdpau-drivers.x86_64            11.1.0-2.20151218.fc23     updates
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