Bonjour
J'ai un ssd sur mon portable et j'utilise une règle udev pour régler le scheduler, en suivant ce vieux sujet : http://forums.fedora-fr.org/viewtopic.php?id=57162 , post #10 :
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.
Par contre je n'avais pas essayé, mais quand je branche une clé usb, le scheduler reste à cfq :
[root@host-192-168-1-2 ~]# fdisk -l

Disque /dev/sda : 238,5 GiB, 256060514304 octets, 500118192 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x0003d2f5

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 3074047 3072000 1,5G 83 Linux
/dev/sda2 3074048 6146047 3072000 1,5G 83 Linux
/dev/sda3 6146048 18434047 12288000 5,9G 82 Linux swap / Solaris
/dev/sda4 18434048 500118191 481684144 229,7G 5 Extended
/dev/sda5 18436096 83972095 65536000 31,3G 83 Linux
/dev/sda6 83974144 149510143 65536000 31,3G 83 Linux
/dev/sda7 149512192 395272191 245760000 117,2G 83 Linux
/dev/sda8 395274240 500118191 104843952 50G 83 Linux

Disque /dev/sdb : 7,2 GiB, 7743995904 octets, 15124992 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x69e9fb83

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 0 8990719 8990720 4,3G 0 Empty
/dev/sdb2 2756 15307 12552 6,1M ef EFI (FAT-12/16/32)
/dev/sdb3 15308 65579 50272 24,6M 0 Empty

[root@host-192-168-1-2 ~]# cat /sys/block/sdb/queue/scheduler
noop deadline [cfq]
Est-ce normal, ou est-ce que quelque chose à changé depuis le sujet précédent ?
Perso j'utilise ce que dit la doc plutôt que l'udev, mais il me semble qu'il y a un truc qui ne fonctionne plus...

C'est l'option "ssd" à mettre dans le fstab qui ne semble plus nécessaire.

Après je n'ai pas testé avec udev, parce que bon ça fonctionne déjà très bien comme ça, donc pas besoin de chercher à faire plus compliqué pour qqchose qui ne bouge pas vraiment.
Ta clé est en sdb. la condition est donc satisfaite : KERNEL=="sd[a-z]"
J'imagine que la deuxième ne l'est pas : ATTR{queue/rotational}=="0"
Je supose que ATTR{queue/rotational}=="0" permet d'être sûr d'avoir affaire à un SSD.
Cela voudrait donc dire qu'une clé usb n'est pas identifié comme un disque ssd ?
Que donne
udevadm info --path /sys/block/sdb
et surtout
cat /sys/block/sdb/queue/rotational
? Après pour une clef usb le scheduler c'est pas trop important.
[dominique@host-192-168-1-2 ~]$ udevadm info --path /sys/block/sdb
P: /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/host8/target8:0:0/8:0:0:0/block/sdb
N: sdb
S: disk/by-id/usb-Lexar_JumpDrive_AAZNXACW2AMQ5M8K-0:0
S: disk/by-label/TAILS\x201.2.2\x20-\x2020141212
S: disk/by-path/pci-0000:00:1d.0-usb-0:1.2:1.0-scsi-0:0:0:0
S: disk/by-uuid/2014-12-12-13-54-44-00
E: DEVLINKS=/dev/disk/by-id/usb-Lexar_JumpDrive_AAZNXACW2AMQ5M8K-0:0 /dev/disk/by-label/TAILS\x201.2.2\x20-\x2020141212 /dev/disk/by-path/pci-0000:00:1d.0-usb-0:1.2:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/2014-12-12-13-54-44-00
E: DEVNAME=/dev/sdb
E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/host8/target8:0:0/8:0:0:0/block/sdb
E: DEVTYPE=disk
E: ID_BUS=usb
E: ID_FS_APPLICATION_ID=The\x20Amnesic\x20Incognito\x20Live\x20System
E: ID_FS_BOOT_SYSTEM_ID=EL\x20TORITO\x20SPECIFICATION
E: ID_FS_LABEL=TAILS_1.2.2_-_20141212
E: ID_FS_LABEL_ENC=TAILS\x201.2.2\x20-\x2020141212
E: ID_FS_PUBLISHER_ID=https:\x2f\x2ftails.boum.org\x2f
E: ID_FS_SYSTEM_ID=LINUX
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: ID_FS_UUID=2014-12-12-13-54-44-00
E: ID_FS_UUID_ENC=2014-12-12-13-54-44-00
E: ID_FS_VERSION=Joliet Extension
E: ID_INSTANCE=0:0
E: ID_MODEL=JumpDrive
E: ID_MODEL_ENC=JumpDrive\x20\x20\x20\x20\x20\x20\x20
E: ID_MODEL_ID=a202
E: ID_PART_TABLE_TYPE=dos
E: ID_PART_TABLE_UUID=6ad7da14
E: ID_PATH=pci-0000:00:1d.0-usb-0:1.2:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-0000_00_1d_0-usb-0_1_2_1_0-scsi-0_0_0_0
E: ID_REVISION=1100
E: ID_SERIAL=Lexar_JumpDrive_AAZNXACW2AMQ5M8K-0:0
E: ID_SERIAL_SHORT=AAZNXACW2AMQ5M8K
E: ID_TYPE=disk
E: ID_USB_DRIVER=usb-storage
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=Lexar
E: ID_VENDOR_ENC=Lexar\x20\x20\x20
E: ID_VENDOR_ID=05dc
E: MAJOR=8
E: MINOR=16
E: MPATH_SBIN_PATH=/sbin
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: UDISKS_PRESENTATION_NOPOLICY=0
E: USEC_INITIALIZED=9148612
[dominique@host-192-168-1-2 ~]$ cat /sys/block/sdb/queue/rotational
1
Je sais que pour une clé usb cela n'est pas important, mais je trouve bizarre que cette règle ne s'applique pas.

Et imagine que j'ai un ssd externe branché en usb, est-ce que la règle s'appliquerait ?
La règle est bonne, mais le système voit la clef USB comme étant quelque chose de mécanique (rotational vaut 1). Etrange ça. Peut être le fait que ça soit une iso dessus? (ID_FS_TYPE=iso9660)

Sinon pour te rassurer, si tu as un SSD branché en USB et que la règle ne s'applique pas ce n'est pas grave non plus. Le changement de scheduler c'est juste du tunning dans le but de tirer profit au maximum des perf d'un SSD, le brancher sur un port USB nous éloigne de ce besoin. Le CFQ n'est pas non plus catastrophique.
Merci madko de ces éclaircissements.
Mais comme tu le dis, voir une clé usb comme un disque rotatif est quand même surprenant.

Je clos le sujet.
Du coup se serait plus un bug kernel ou udev, voir une clef usb en rotational 1 c'est pas logique.

J'ai trouvé ce rapport mais chez ubuntu: https://bugs.launchpad.net/linux/+bug/499237

Je viens de tester avec une clef qui n'est pas vu comme une ISO:
➜  ~  udevadm info --path /sys/block/sdc
P: /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/host7/target7:0:0/7:0:0:0/block/sdc
N: sdc
S: disk/by-id/usb-JetFlash_Transcend_64GB_850CDH7173U2CBB0-0:0
S: disk/by-path/pci-0000:00:14.0-usb-0:4:1.0-scsi-0:0:0:0
E: DEVLINKS=/dev/disk/by-id/usb-JetFlash_Transcend_64GB_850CDH7173U2CBB0-0:0 /dev/disk/by-path/pci-0000:00:14.0-usb-0:4:1.0-scsi-0:0:0:0
E: DEVNAME=/dev/sdc
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/host7/target7:0:0/7:0:0:0/block/sdc
E: DEVTYPE=disk
E: ID_BUS=usb
E: ID_INSTANCE=0:0
E: ID_MODEL=Transcend_64GB
E: ID_MODEL_ENC=Transcend\x2064GB\x20\x20
E: ID_MODEL_ID=1000
E: ID_PART_TABLE_TYPE=dos
E: ID_PART_TABLE_UUID=c3072e18
E: ID_PATH=pci-0000:00:14.0-usb-0:4:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_4_1_0-scsi-0_0_0_0
E: ID_REVISION=1100
E: ID_SERIAL=JetFlash_Transcend_64GB_850CDH7173U2CBB0-0:0
E: ID_SERIAL_SHORT=850CDH7173U2CBB0
E: ID_TYPE=disk
E: ID_USB_DRIVER=usb-storage
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=JetFlash
E: ID_VENDOR_ENC=JetFlash
E: ID_VENDOR_ID=8564
E: MAJOR=8
E: MINOR=32
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=57725167
Et donc:
➜  ~  cat /sys/block/sdc/queue/rotational 
1
Mais, suprirse...
➜  ~  cat /sys/block/sdc/queue/scheduler 
noop [deadline] cfq 
Ce qui n'est pas non plus logique!
Super, je vais suivre ça aussi 🙂