mptscsih: ioc0: przerwanie zadania: SUKCES (rv = 2002) powoduje zawieszenie się na 30 sekund

We / wy do mojego oprogramowania RAID6 często zawiesza się na około 30 sekund, po czym wszystko wraca do normy.

Po zakończeniu zamrażania jest ono umieszczane w 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)

Znalazłem błąd i ktoś zasugerował użycie 1,5 Gb / s zamiast 3,0 Gb / s. Za pomocą lsiutilzmieniłem prędkość łącza:

# 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

To nie pomogło.

Próbowałem zmienić „Device Missing I / O Delay” na 32. To też nie pomogło.

Próbowałem zmienić limit czasu / sys / class / scsi_device / * / device / timeout z 30 na 100, a następnie na 3. Wszystko nie powiodło się.

$ 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

Problem występuje niezwykle rzadko, jeśli są tylko operacje odczytu lub zapisu: bez problemu mogę odczytać lub zapisać 1 TB. Problem wydaje się pojawiać, gdy istnieją zarówno operacje odczytu, jak i zapisu. Na raid6 dzieje się tak, jeśli napiszesz plik mniejszy niż rozmiar paska, a pasek nie jest już buforowany (w takim przypadku pasek należy odczytać, aby obliczyć nową sumę kontrolną).

System nie jest maszyną wirtualną.

Co powoduje problem? Jak pozbyć się 30 sekund zamrażania?

Edycja: dodatkowe testy

Znalazłem ładny zestaw testowy, który wydaje się wywoływać problem. Zawiera pliki mniejsze niż rozmiar paska, co wymusza ponowne obliczenie parzystości, co wymusza wiele odczytów w połączeniu z zapisem.

Muszę przyznać, że nie sądziłem, że harmonogram kolejek miałby jakikolwiek wpływ na ten problem. Myliłem się. Oczywiste jest, że deadlinejest znacznie gorszy od innych. Jednak żadne z nich nie rozwiązało problemu.

# cat /sys/block/sdaa/queue/scheduler
noop deadline [cfq]

Zmiana harmonogramu nooppowoduje, że problem pojawia się po 100-120 sekundach.

parallel echo noop \> {} ::: /sys/block/sd*/queue/scheduler

Zmiana harmonogramu deadlinepowoduje, że problem pojawia się po 20-30 sekundach.

parallel echo deadline \> {} ::: /sys/block/sd*/queue/scheduler

Zmiana harmonogramu cfqpowoduje, że problem pojawia się po 120-300 sekundach.

parallel echo cfq \> {} ::: /sys/block/sd*/queue/scheduler

Edytuj2

Ponieważ harmonogram ma wpływ, zastanawiam się, czy przyczyną problemu jest zbyt wiele żądań w określonym przedziale czasowym. Czy mogę w jakiś sposób ograniczyć liczbę żądań wysyłanych na sekundę?

MPTSCSIH kierowca wydaniu z LSI interesować.

Major Changes For Version 2.06.75.00-1
Release Date:  12/10/2007

General Changes
Functionality
•   Task Aborts for commands to a Volume are returned as FAILED and not sent to FW.

Która wersja jest twoim sterownikiem? ( modinfo mptscsih)

Użyj tego linku, aby uzyskać informacje o oprogramowaniu firmy Seagate na temat dysku Barracuda 3 TB. Musisz podać numer seryjny, aby uzyskać szczegółowe informacje.

Aktualizacja: Wypróbuj smartctl -i /dev/sdaaWłaśnie przetestowałem to na SCSI i SATA i w ten sposób uzyskałem numer seryjny.

Czy próbowałeś zmienić harmonogramy we / wy?

   mccoy:/sys/block/sdb/queue # cat scheduler 
   noop anticipatory deadline [cfq] 
   mccoy:/sys/block/sdb/queue # echo noop > scheduler 
   mccoy:/sys/block/sdb/queue # cat scheduler 
   [noop] anticipatory deadline cfq 

Domyślną wartością jest CFQ typowo dla większości systemów „obecnie”.

Aby porównać harmonogramy we / wy, wykonaj następujące czynności:

Czytaj testy:

# echo 3 > /proc/sys/vm/drop_caches

Zapewni to, że testujesz dysk, a nie buforowane strony pamięci RAM, spowoduje to opróżnienie pamięci podręcznej.

Napisz test:

Kopiuj pliki wiele razy jednocześnie. Po zakończeniu zapisywania wydania async

Jeśli testujesz oba, możesz chcieć drop_cachesi zadzwonić syncpo zakończeniu kopiowania. Oprócz programu planującego istnieją opcje dostrajania dla każdego programu planującego. Ale szybkim testem byłaby zmiana harmonogramu i ponowna próba. Jeśli masz dobry kontroler noop, odrzuci do niego „Planowanie we / wy” i nie wykona żadnego planowania danych na poziomie systemu operacyjnego.

W każdym razie warto spróbować, a to trwa tylko echoustawić go z powrotem.

Rozwiązałem problem, kupując kartę SAS2008. Wciąż trochę narzeka w dzienniku, ale nigdy nie blokuje wejścia / wyjścia dysku. Testowałem także, że obsługuje dyski SATA 4 TB, podczas gdy LSI-SAS1068E obsługuje tylko 2 TB.

Ponieważ zwracam LSI-SAS1068E sprzedawcy, nie będę mógł wypróbować innych sugestii. Dlatego zamykam pytanie tutaj.