Bonjour.
J'ai un disque dur ssd, et pour l'optimiser je suis la doc : http://doc.fedora-fr.org/wiki/Les_SSD_sous_fedora

Mais j'ai un problème avec F17 (que je n'avais pas sous F16) avec cette partie :
4.2 Changer le disk scheduler du noyau (SSD)

Oulà jeune homme, ne m'insultez pas !

Le disk scheduler, c'est (en gros) un programme qui va gérer comment sont envoyées les ordres de lecture/écriture au volume de stockage (disque dur, SSD, clé USB, ...). Par défaut, le scheduler va essayer autant que possible de faire des lectures/écritures dans des zones proches géographiquement sur le disque dur afin de faciliter le travail de la tête de lecture et ainsi d'améliorer les performances.

Sauf que vous comprenez bien que ce problème n'existe pas dans le cas d'un SSD : il n'y a pas de zones géographiques : tout est stocké dans des puces mémoire. Il n'y a donc pas besoin de traiter les informations avant de les envoyer au SSD.

On va tout d'abord vérifier le scheduler utilisé pour le SSD (on considère que votre SSD est sda) :

# cat /sys/block/sda/queue/scheduler

La réponse devrait être

noop deadline [cfq]

Le paramètre entre crochets est celui actuellement utilisé.

cfq étant le scheduler adapté aux disques durs. On va le changer pour noop qui est un scheduler qui va envoyer les requêtes à la chaîne sans se soucier de leur position géographique, ce qui aura pour effet de légèrement soulager votre processeur mais surtout d'éviter des calculs inutiles.

Pour cela, ouvrir un terminal :

# vim /etc/rc.local

Ajouter la ligne suivante à la fin du fichier, sauvegarder puis quitter vim :

echo 'noop' > /sys/block/sda/queue/scheduler
Avec F16, je crée le fichier rc.local dans /etc, et tout fonctionnai avec le service "rc-local.service"

Avec F17, le service n'est pas activé par défaut, et impossible de l'activer : 
[root@host ~]# systemctl enable rc-local.service
Warning: unit files do not carry install information. No operation executed.
[root@host ~]#

[root@host ~]# systemctl start rc-local.service
Job failed. See system journal and 'systemctl status' for details.
[root@host ~]#

[root@host ~]# systemctl status rc-local.service
rc-local.service - /etc/rc.d/rc.local Compatibility
          Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
          Active: inactive (dead)
          CGroup: name=systemd:/system/rc-local.service
Quelqu'un a une idée ?
bon en cherchant un peu, il faut créer le fichier rc.local dans /etc/rc.d et non dans /etc
[root@host ~]# systemctl status rc-local.service
rc-local.service - /etc/rc.d/rc.local Compatibility
          Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
          Active: active (exited) since Fri, 01 Jun 2012 19:38:51 +0200; 42s ago
         Process: 586 ExecStart=/etc/rc.d/rc.local start (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/rc-local.service

[dominique@host ~]$ systemd-analyze blame
   728ms fedora-storage-init.service
   568ms akmods.service
   323ms udev-settle.service
   237ms lm_sensors.service
   237ms NetworkManager.service
   225ms mcelog.service
   193ms udev-trigger.service
   191ms systemd-logind.service
   167ms avahi-daemon.service
   149ms auditd.service
   123ms acpid.service
   116ms irqbalance.service
   108ms rsyslog.service
    91ms systemd-readahead-collect.service
    82ms dbus.service
    78ms gpm.service
    73ms systemd-readahead-replay.service
    72ms systemd-binfmt.service
    67ms fedora-readonly.service
    66ms udisks2.service
    63ms systemd-user-sessions.service
    58ms systemd-remount-fs.service
    58ms media.mount
    54ms systemd-tmpfiles-setup.service
    50ms fedora-loadmodules.service
    49ms sys-kernel-debug.mount
    45ms boot.mount
    44ms home.mount
    42ms systemd-vconsole-setup.service
    36ms dev-mqueue.mount

    33ms rc-local.service <==

    31ms systemd-sysctl.service
    23ms fedora-wait-storage.service
    23ms fedora-storage-init-late.service
    20ms sys-kernel-config.mount
    17ms dev-hugepages.mount
    16ms udev.service
     9ms proc-sys-fs-binfmt_misc.mount
     8ms rtkit-daemon.service
     5ms upower.service
[dominique@host ~]$

Mais cela ne résout pas le problème, j'ai toujours : 
[dominique@host ~]$ cat /sys/block/sda/queue/scheduler
[noop] deadline cfq
Mon fichier rc.local 
#!/bin/bash
echo 'noop' > /sys/block/sda/queue/scheduler
Ton second problème n'existe pas : c'est déjà "noop" qui est sélectionné, c'est bon.
Ou alors j'ai mal compris.
Valdes wrote:Ton second problème n'existe pas : c'est déjà "noop" qui est sélectionné, c'est bon.
Ou alors j'ai mal compris.
Non, c'est moi qui est compris à l'envers...

C'est tout bon, faut juste signaler de modifier la documentation, c'est à dire créer le fichier rc.local dans /etc/rc.d et non dans /etc
25 jours plus tard
Merci à vous 2. 🙂

Votre discussion m'a vraiment aidé (surtout que je n'avais pas vu que la page de la documentation avait été modifiée)

J'ai installé un ssd dans mon netbook, et comme chepioq, je n'arrivais pas à changer le scheduler.
Résultat j'ai tourné avec 'cfq' jusqu'à maintenant, j'espère que ca n'a pas trop endommagé mon ssd... 🙁

Au fait, le meilleur scheduler pour un ssd, c'est 'noop' ou 'deadline'?
Salut.

T'inquiètes, le scheduler n'abîme absolument pas ton SSD (cf la doc). Et toujours selon la doc, le meilleur pour un SSD, c'est noop.
Y-a-un-truc qui me chiffonne. Et quand je suis tout froissé j'aime pas :-D

Cela fait au moins depuis Fedora 7 que j'utilise régulièrement rc.local.
Et rc.local n'a jamais été dans /etc.
Il a toujours été dans /etc/rc.d !

C'est juste la doc SSD qui comportait une erreur ...

Voilà, je suis défroissé :-P
exact et il y avait un lien vers /etc/rc.local
6 mois plus tard
Bonsoir à tous,

Edit : j'ai oublié de le rendre exécutable ... quel idiot 😉
C'EST DONC RESOLU...

J'ai également un problème avec ce point, même en plaçant le fichier rc.local dans rc.d
[root@portable rc.d]# systemctl enable rc-local.service
The unit files have no [Install] section. They are not meant to be enabled using systemctl.
[root@portable rc.d]# systemctl start rc-local.service
Job failed. See system journal and 'systemctl status' for details.
Et dans le détail, pour vérif : 
[root@portable rc.d]# ls
init.d  rc0.d  rc1.d  rc2.d  rc3.d  rc4.d  rc5.d  rc6.d  rc.local
[root@portable rc.d]# systemctl status rc-local.service
rc-local.service - /etc/rc.d/rc.local Compatibility
	  Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
	  Active: failed (Result: exit-code) since Tue, 08 Jan 2013 19:21:13 +0100; 2min 20s ago
	 Process: 2344 ExecStart=/etc/rc.d/rc.local start (code=exited, status=203/EXEC)
	  CGroup: name=systemd:/system/rc-local.service

J'ai peut-être loupé quelque-chose...
Merci à vous!
C'est suite à systemd que le fichier se trouve uniquement dans /etc/rc.d avant on pouvait simplement faire un fichier /etc/rc.local et c'était plier. Là faut le faire dans rc.d et activer le service, c'est ça le progrès 🙂

Pour ceux que ça interesse, suivant l'excellente doc ssd http://doc.fedora-fr.org/wiki/Les_SSD_sous_fedora j'ai zappé le rc.local pour passer plutôt par udev (qui se charge plus tôt me semble):
# disques sans rotation => noop
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"
Avec ça udev quand il rencontre un périphérique de type /dev/sdXX, même ajouté après le boot, et que celui-ci n'est pas un disque dur classique (le queue/rotational à 0 l'indique normalement), donc un SSD ou une clef usb, il positionne le scheduler à noop.

J'ai testé deadline c'est kif kif.
madko wrote:C'est suite à systemd que le fichier se trouve uniquement dans /etc/rc.d avant on pouvait simplement faire un fichier /etc/rc.local et c'était plier. Là faut le faire dans rc.d et activer le service, c'est ça le progrès 🙂

Pour ceux que ça interesse, suivant l'excellente doc ssd http://doc.fedora-fr.org/wiki/Les_SSD_sous_fedora j'ai zappé le rc.local pour passer plutôt par udev (qui se charge plus tôt me semble):
# disques sans rotation => noop
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"
Avec ça udev quand il rencontre un périphérique de type /dev/sdXX, même ajouté après le boot, et que celui-ci n'est pas un disque dur classique (le queue/rotational à 0 l'indique normalement), donc un SSD ou une clef usb, il positionne le scheduler à noop.

J'ai testé deadline c'est kif kif.
Cela serait peut-être bien de rajouter cette méthode dans la doc sur les ssd...
On aimerait avoir des retours avant de la mettre dans la doc. J'ai que des SSD ocz et cette ligne marche niquel, mais est-ce vraiment le cas pour tous les SSD?

J'ai cru aussi comprendre que le TRIM maintenant n'était plus tant nécessaire que ça, la fameuse option discards pour ext4. Les SSD récents ont un garbage collector qui s'occupe de ça maintenant. A voir s'il faut pas commencer à l'indiquer dans la doc aussi.

Dans ce fichier 99-ssd.rules j'ai ajouter aussi ça: 
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/read_ahead_kb}="1024"
ça augmente ce que le kernel lit en avance sur le périphérique, car souvent quand on commence à lire un bout de fichier, on demande souvent la suite. Ya surement encore plein de trucs comme ça...

Et sinon il y a encore plus simple que le rc.local ou les règles udev, pour un pc/portable qui n'aurait que du SSD, dans /etc/default/grub d'ajouter 
elevator=noop
pour GRUB_CMDLINE_LINUX. Puis régénérer la conf grub2:
grub2-mkconfig -o /boot/grub2/grub.cfg
Du coup là on est en noop encore plus tôt dans la phase de boot. L'inconvénient c'est que tout est en noop, si on branche un DD externe, il sera logiquement un noop. C'est pas si grave mais il faut le savoir.