Les E / S vers mon logiciel RAID6 se bloquent souvent pendant environ 30 secondes, après quoi tout revient à la normale.
Une fois le gel terminé, ceci est mis dans syslog:
Mar 14 18:43:57 server kernel: [35649.816060] sd 5:0:23:0: [sdy] CDB: Read(10): 28 00 6c 52 68 58 00 04 00 00
Mar 14 18:43:58 server kernel: [35651.149020] mptbase: ioc0: LogInfo(0x31140000): Originator={PL}, Code={IO Executed}, SubCode(0x0000) cb_idx mptscsih_io_done
Mar 14 18:43:58 server kernel: [35651.151962] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff8807b02dfe80)
Mar 14 18:43:58 server kernel: [35651.151967] mptscsih: ioc0: attempting task abort! (sc=ffff88002a7f30c0)
Mar 14 18:43:58 server kernel: [35651.151972] sd 5:0:23:0: [sdy] CDB: Read(10): 28 00 6c 52 6c 58 00 04 00 00
Mar 14 18:43:58 server kernel: [35651.151981] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff88002a7f30c0)
Mar 14 18:43:58 server kernel: [35651.151984] mptscsih: ioc0: attempting task abort! (sc=ffff8804120e5ec0)
Mar 14 18:43:58 server kernel: [35651.151988] sd 5:0:23:0: [sdy] CDB: Read(10): 28 00 6c 52 70 58 00 04 00 00
Mar 14 18:43:58 server kernel: [35651.151996] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff8804120e5ec0)
Mar 14 18:43:58 server kernel: [35651.151999] mptscsih: ioc0: attempting task abort! (sc=ffff880154afb280)
Mar 14 18:43:58 server kernel: [35651.152020] sd 5:0:23:0: [sdy] CDB: Read(10): 28 00 6c 52 74 58 00 04 00 00
Mar 14 18:43:58 server kernel: [35651.152029] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff880154afb280)
J'ai googlé l'erreur et quelqu'un a suggéré d'essayer d'utiliser 1,5 Gbps au lieu de 3,0 Gbps. En utilisant lsiutilj'ai changé la vitesse du lien:
# lsiutil -p 1 -i
Firmware Settings
-----------------
SAS WWID: 500605b002c0f680
Multi-pathing: Disabled
SATA Native Command Queuing: Enabled
SATA Write Caching: Enabled
SATA Maximum Queue Depth: 32
Device Missing Report Delay: 0 seconds
Device Missing I/O Delay: 0 seconds
Phy Parameters for Phynum: 0 1 2 3 4 5 6 7
Link Enabled: Yes Yes Yes Yes Yes Yes Yes Yes
Link Min Rate: 1.5 1.5 1.5 1.5 1.5 1.5 1.5 1.5
Link Max Rate: 1.5 1.5 1.5 1.5 1.5 1.5 1.5 1.5
SSP Initiator Enabled: Yes Yes Yes Yes Yes Yes Yes Yes
SSP Target Enabled: No No No No No No No No
Port Configuration: Auto Auto Auto Auto Auto Auto Auto Auto
Target IDs per enclosure: 1
Persistent mapping: Enabled
Physical mapping type: None
Target ID 0 reserved for boot: No
Starting slot (direct attach): 0
Target IDs (physical mapping): 8
Interrupt Coalescing: Enabled, timeout is 16 us, depth is 4
Cela n'a pas aidé.
J'ai essayé de changer «Périphérique manquant I / O Delay» à 32. Cela n'a pas aidé non plus.
J'ai essayé de changer / sys / class / scsi_device / * / device / timeout de 30 à 100 puis à 3. Tout a échoué.
$ uname -a
Linux server 3.2.0-0.bpo.1-amd64 #1 SMP Sat Feb 11 08:41:32 UTC 2012 x86_64 GNU/Linux
$ grep LSISAS1068E /var/log/messages
Mar 13 15:47:44 server kernel: [ 21.082363] scsi5 : ioc0: LSISAS1068E B3, FwRev=01210000h, Ports=1, MaxQ=483, IRQ=45
$ modinfo mptscsih
filename: /lib/modules/3.2.0-0.bpo.1-amd64/kernel/drivers/message/fusion/mptscsih.ko
version: 3.04.20
license: GPL
description: Fusion MPT SCSI Host driver
author: LSI Corporation
srcversion: 85D42A00FEBA3C95555E3AF
depends: scsi_mod,mptbase
intree: Y
vermagic: 3.2.0-0.bpo.1-amd64 SMP mod_unload modversions
$ cat /sys/block/sdae/device/model
ST3000DM001-9YN1
$ cat /sys/block/sdae/device/rev
CC4C
Le problème se produit extrêmement rarement s'il n'y a que des opérations de lecture ou d'écriture: je peux lire ou écrire 1 To sans problème. Le problème semble se poser quand il y a deux opérations de lecture et d' écriture. Sur un raid6, cela se produit si vous écrivez un fichier plus petit que la taille de la bande et que la bande n'est pas déjà mise en cache (auquel cas la bande doit être lue pour calculer la nouvelle somme de contrôle).
Le système n'est pas une machine virtuelle.
Quelle est la cause du problème? Comment puis-je me débarrasser des 30 secondes de gel?
Edit: tests supplémentaires
J'ai trouvé un bel ensemble de tests qui semble provoquer le problème. Il contient des fichiers plus petits que la taille de bande, ce qui oblige à recalculer la parité, forçant ainsi un grand nombre de lectures combinées aux écritures.
Je dois admettre que je ne pensais pas que le planificateur de file d'attente aurait un effet sur ce problème. J'avais tort. Il est clair que deadlinec'est bien pire que les autres. Cependant, aucun d'entre eux ne résout le problème.
# cat /sys/block/sdaa/queue/scheduler
noop deadline [cfq]
La modification de l'ordonnanceur noopentraîne l'apparition du problème après 100 à 120 secondes.
parallel echo noop \> {} ::: /sys/block/sd*/queue/scheduler
La modification de l'ordonnanceur deadlineentraîne l'apparition du problème après 20 à 30 secondes.
parallel echo deadline \> {} ::: /sys/block/sd*/queue/scheduler
La modification de l'ordonnanceur cfqentraîne l'apparition du problème après 120 à 300 secondes.
parallel echo cfq \> {} ::: /sys/block/sd*/queue/scheduler
Modifier2
Étant donné que le planificateur a un effet, je pense que si le problème est causé par trop de demandes dans un délai. Puis-je en quelque sorte limiter le nombre de demandes envoyées par seconde?