I / O ของซอฟต์แวร์ RAID6 มักค้างประมาณ 30 วินาทีหลังจากนั้นทุกอย่างกลับสู่ปกติ
หลังจากการแช่แข็งสิ้นสุดลงสิ่งนี้จะถูกใส่ลงใน 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)
ฉัน googled ข้อผิดพลาดและมีคนแนะนำให้ลองใช้ 1.5Gbps แทน 3.0Gbps ใช้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 I Missing I / O Delay' เป็น 32 ซึ่งไม่ได้ช่วยเช่นกัน
ฉันพยายามเปลี่ยน / sys / class / scsi_device / * / อุปกรณ์ / หมดเวลาจาก 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
ปัญหาเกิดขึ้นน้อยมากหากมีการดำเนินการอ่านหรือเขียนเท่านั้น: ฉันสามารถอ่านหรือเขียน 1 TB ได้โดยไม่มีปัญหา ปัญหาน่าจะเกิดขึ้นเมื่อมีทั้งการอ่านและเขียน ใน raid6 ที่เกิดขึ้นถ้าคุณเขียนไฟล์เล็กกว่าขนาดสตริปและคุณไม่มีสไทรพ์แคชอยู่แล้ว (ในกรณีนี้สตริปจะต้องอ่านเพื่อคำนวณค่าเช็คซัมใหม่)
ระบบไม่ใช่เครื่องเสมือน
อะไรคือสาเหตุของปัญหา ฉันจะกำจัดการแช่แข็ง 30 วินาทีได้อย่างไร
แก้ไข: การทดสอบเพิ่มเติม
ฉันพบชุดการทดสอบที่ดีซึ่งดูเหมือนว่าจะกระตุ้นปัญหา มันมีไฟล์ที่เล็กกว่าขนาดสตริปจึงบังคับให้คำนวณใหม่ของความเท่าเทียมกันจึงบังคับให้มีการอ่านจำนวนมากรวมกับการเขียน
ฉันต้องยอมรับว่าฉันไม่คิดว่าตัวจัดคิวจะมีผลกระทบกับปัญหานี้ ฉันผิดไป. เป็นที่ชัดเจนว่าdeadlineเลวร้ายยิ่งกว่าคนอื่น ๆ ไม่มีใครแก้ปัญหาได้
# cat /sys/block/sdaa/queue/scheduler
noop deadline [cfq]
การเปลี่ยนกำหนดการเพื่อnoopทำให้ปัญหาเกิดขึ้นหลังจาก 100-120 วินาที
parallel echo noop \> {} ::: /sys/block/sd*/queue/scheduler
การเปลี่ยนกำหนดการเพื่อdeadlineทำให้ปัญหาเกิดขึ้นหลังจาก 20-30 วินาที
parallel echo deadline \> {} ::: /sys/block/sd*/queue/scheduler
การเปลี่ยนกำหนดการเพื่อcfqทำให้ปัญหาเกิดขึ้นหลังจาก 120-300 วินาที
parallel echo cfq \> {} ::: /sys/block/sd*/queue/scheduler
Edit2
เนื่องจากตัวกำหนดตารางเวลามีผลฉันคิดว่าปัญหาเกิดจากการร้องขอมากเกินไปในกรอบเวลา ฉันสามารถเร่งจำนวนคำขอที่ส่งต่อวินาทีได้ไหม?