L'I / O sul mio software RAID6 spesso si blocca per circa 30 secondi, dopodiché tutto torna alla normalità.
Al termine del blocco, questo viene inserito in 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)
Ho cercato su Google l'errore e qualcuno mi ha suggerito di provare a utilizzare 1,5 Gbps invece di 3,0 Gbps. Usando lsiutilho cambiato la velocità del collegamento:
# 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
Questo non ha aiutato.
Ho provato a cambiare "Ritardo I / O dispositivo mancante" su 32. Neanche questo mi ha aiutato.
Ho provato a cambiare / sys / class / scsi_device / * / device / timeout da 30 a 100 e poi a 3. Tutto fallito.
$ 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
Il problema si verifica estremamente raramente se ci sono solo operazioni di lettura o scrittura: posso leggere o scrivere 1 TB senza problemi. Il problema sembra sorgere quando ci sono entrambe le operazioni di lettura e scrittura. Su un raid6 che si verifica se si scrive un file più piccolo della dimensione della striscia e non si dispone già della cache nella cache (nel qual caso la striscia deve essere letta per calcolare il nuovo checksum).
Il sistema non è una macchina virtuale.
Qual è la causa del problema? Come posso eliminare i 30 secondi di congelamento?
Modifica: test aggiuntivi
Ho trovato un bel set di test che sembra provocare il problema. Contiene file più piccoli della dimensione della striscia, forzando così la ricompilazione della parità forzando così molte letture combinate con le scritture.
Devo ammettere che non pensavo che il programmatore di coda avrebbe avuto alcun effetto su questo problema. Mi sbagliavo. È chiaro che deadlineè molto peggio degli altri. Nessuno di loro risolve il problema, però.
# cat /sys/block/sdaa/queue/scheduler
noop deadline [cfq]
La modifica dello scheduler per noopcausare il problema dopo 100-120 secondi.
parallel echo noop \> {} ::: /sys/block/sd*/queue/scheduler
La modifica dello scheduler in deadlinemodo da far insorgere il problema dopo 20-30 secondi.
parallel echo deadline \> {} ::: /sys/block/sd*/queue/scheduler
La modifica dello scheduler in cfqmodo da far insorgere il problema dopo 120-300 secondi.
parallel echo cfq \> {} ::: /sys/block/sd*/queue/scheduler
Edit2
Poiché lo scheduler ha un effetto, sto pensando se il problema è causato da troppe richieste in un arco di tempo. Posso in qualche modo limitare il numero di richieste inviate al secondo?