☰

mptscsih: ioc0: 작업이 중단되었습니다. SUCCESS(rv=2002)로 인해 30초 동안 정지됩니다.

tag-icon • tag-icon linux-kernel drivers scsi timeout
mptscsih: ioc0: 작업이 중단되었습니다. SUCCESS(rv=2002)로 인해 30초 동안 정지됩니다.

내 소프트웨어 RAID6의 I/O가 종종 약 30초 동안 정지된 다음 모든 것이 정상으로 돌아갑니다.

동결이 끝나면 시스템 로그에 다음 내용이 기록됩니다.

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)

오류를 검색해 보니 누군가 3.0Gbps 대신 1.5Gbps를 시도해 보라고 제안했습니다. 다음을 사용하여 lsiutil링크 속도를 변경했습니다 .

# 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

그것은 도움이 되지 않습니다.

"Device Lost I/O Delay"를 32로 변경해 보았습니다. 이것도 도움이 되지 않습니다.

/sys/class/scsi_device/*/device/timeout을 30에서 100으로 변경한 다음 3으로 변경해 보았습니다. 모두 실패했습니다.

$ 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

읽기 또는 쓰기 작업만 있는 경우에는 이 문제가 거의 발생하지 않습니다. 1TB를 문제 없이 읽거나 쓸 수 있습니다. 다음과 같은 경우에 문제가 발생하는 것 같습니다.둘 다읽기 및 쓰기 작업. raid6에서는 작성한 파일이 스트라이프 크기보다 작고 스트라이프가 캐시되지 않은 경우에 이런 일이 발생합니다(이 경우 새 체크섬을 계산하려면 스트라이프를 읽어야 합니다).

이 시스템은 가상 머신이 아닙니다.

이 문제의 원인은 무엇입니까? 30초 멈춤 현상을 해결하는 방법은 무엇입니까?

편집: 추가 테스트

이 문제를 유발하는 것으로 보이는 좋은 테스트 세트를 찾았습니다. 여기에는 스트라이프 크기보다 작은 파일이 포함되어 있어 패리티를 다시 계산해야 하므로 과도한 읽기와 쓰기가 결합됩니다.

인정해야겠습니다. 대기열 스케줄러가 이 문제에 아무런 영향을 미치지 않을 것이라고 생각합니다. 내가 틀렸어. 분명히 deadline다른 사람들보다 훨씬 나쁩니다. 그러나 그들 중 누구도 문제를 해결하지 못합니다.

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

스케줄러를 변경하면 noop100-120초 후에 문제가 발생합니다.

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

스케줄러를 변경하면 deadline20~30초 후에 문제가 발생합니다.

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

스케줄러를 변경하면 cfq120~300초 후에 문제가 발생합니다.

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

편집 2

스케줄러의 영향이 있기 때문에 한 시간 내에 너무 많은 요청으로 인해 문제가 발생하는 것인지 궁금합니다. 초당 전송되는 요청 수를 어떻게든 제한할 수 있나요?

답변1

이것LSI용 MPTSCSIH 드라이버 릴리스 노트재미있을 것 같습니다.

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.

드라이버 버전이 무엇입니까? ( modinfo mptscsih)

이 링크를 사용하세요씨게이트Barracuda 3TB 하드 드라이브에 대한 펌웨어 정보입니다. 세부정보를 확인하려면 일련번호를 입력해야 합니다.

업데이트: 한번 시도해 보세요. smartctl -i /dev/sdaa방금 SCSI와 SATA에서 테스트한 결과 일련 번호를 이런 식으로 얻었습니다.

답변2

I/O 스케줄러를 변경해 보셨나요?

   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

"현재" 대부분의 시스템의 경우 기본값은 일반적으로 CFQ입니다.

I/O 스케줄러를 비교하려면 다음을 수행하십시오.

읽기 테스트:

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

이렇게 하면 RAM이 아닌 디스크에서 캐시된 페이지를 테스트하여 캐시를 플러시하게 됩니다.

테스트를 작성하세요:

파일을 동시에 여러 번 복사하세요. 쓰기가 완료되면sync

두 가지를 모두 테스트하는 경우 복사가 완료된 후 전화해 보시기 바랍니다 drop_caches. sync스케줄러 외에도 각 스케줄러에는 조정 가능한 매개변수가 있습니다. 그러나 빠른 테스트는 스케줄러를 변경하고 다시 시도하는 것입니다. 좋은 컨트롤러가 있는 경우 noop"I/O 스케줄링"이 해당 컨트롤러로 오프로드되고 OS 수준 데이터 스케줄링이 수행되지 않습니다.

echo어쨌든 시도해 볼 가치가 있으며 이전 위치로 돌아가는 데 시간이 걸립니다 .

답변3

저는 SAS2008 카드를 구입하여 이 문제를 해결했습니다. 여전히 로그에 약간의 불만이 있지만 디스크 I/O를 차단하지 않습니다. 또한 LSI-SAS1068E는 2TB만 지원하는 반면 4TB SATA 드라이브를 지원하는지 테스트했습니다.

LSI-SAS1068E를 판매자에게 반품할 예정이므로 다른 제안을 시도할 수 없습니다. 그럼 이번 질문은 여기서 마치겠습니다.

관련 정보