mptscsih: ioc0: hủy bỏ nhiệm vụ: THÀNH CÔNG (rv = 2002) gây ra đóng băng 30 giây


12

I / O cho phần mềm RAID6 của tôi thường đóng băng trong khoảng 30 giây sau đó mọi thứ trở lại bình thường.

Sau khi đóng băng xong, điều này được đưa vào 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)

Tôi đã xử lý lỗi và ai đó đề nghị thử sử dụng 1.5Gbps thay vì 3.0Gbps. Sử dụng lsiutiltôi đã thay đổi tốc độ liên kết:

# 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

Điều đó không giúp được gì.

Tôi đã thử thay đổi 'Thiếu thiết bị trễ I / O' thành 32. Điều đó cũng không giúp được gì.

Tôi đã thử thay đổi / sys / class / scsi_device / * / device / timeout từ 30 đến 100 và sau đó đến 3. Tất cả đều thất bại.

$ 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

Vấn đề xảy ra cực kỳ hiếm khi chỉ có các thao tác đọc hoặc ghi: Tôi có thể đọc hoặc viết 1 TB mà không gặp vấn đề gì. Vấn đề dường như phát sinh khi có cả hoạt động đọc và ghi. Trên raid6 xảy ra nếu bạn viết một tệp nhỏ hơn kích thước sọc và bạn chưa có bộ đệm được lưu trong bộ đệm (trong trường hợp đó, dải phải được đọc để tính toán tổng kiểm tra mới).

Hệ thống không phải là một máy ảo.

Cái gì là nguyên nhân của vấn đề? Làm thế nào để tôi thoát khỏi 30 giây đóng băng?

Chỉnh sửa: kiểm tra bổ sung

Tôi đã tìm thấy một bộ thử nghiệm tốt mà dường như gây ra vấn đề. Nó chứa các tệp nhỏ hơn kích thước sọc do đó buộc tính toán lại tính chẵn lẻ, do đó buộc phải đọc rất nhiều kết hợp với ghi.

Tôi phải thừa nhận rằng tôi đã không nghĩ rằng bộ lập lịch xếp hàng sẽ có bất kỳ ảnh hưởng nào đến vấn đề này. Tôi đã sai. Rõ ràng deadlinelà tồi tệ hơn nhiều so với những người khác. Không ai trong số họ giải quyết vấn đề, mặc dù.

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

Thay đổi lịch trình để noopgây ra sự cố phát sinh sau 100-120 giây.

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

Thay đổi lịch trình để deadlinegây ra vấn đề phát sinh sau 20-30 giây.

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

Thay đổi lịch trình để cfqgây ra sự cố phát sinh sau 120-300 giây.

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

Chỉnh sửa2

Vì bộ lập lịch có ảnh hưởng nên tôi nghĩ nếu sự cố xảy ra do quá nhiều yêu cầu trong khung thời gian. Tôi có thể bằng cách nào đó điều tiết số lượng yêu cầu được gửi mỗi giây không?

Câu trả lời:


5

Các Release Notes MPTSCSIH-Driver từ LSI cái nhìn thú vị.

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.

Phiên bản nào là trình điều khiển của bạn? ( modinfo mptscsih)

Sử dụng liên kết này để biết thông tin về Seagate Firmware về ổ đĩa Barracuda 3 TB của bạn. Bạn phải nhập số sê-ri để biết chi tiết.

Cập nhật: Hãy thử smartctl -i /dev/sdaaTôi vừa thử nó trên SCSI và SATA và nhận được số sê-ri theo cách đó.


Những phần nào của ghi chú phát hành trình điều khiển mà bạn thấy có liên quan đến vấn đề này? Làm cách nào để tìm số sê-ri bằng GNU / Linux trên các đĩa đang sản xuất? Và bạn mong đợi điều gì từ Seagate về điều này? Phiên bản của mptscsih được cập nhật trong câu hỏi.
Ole Tange

@OleTange Tôi đã chèn phần "thú vị". Mặc dù trình điều khiển của bạn dường như mới hơn nhưng đó có thể là một vấn đề cũ xuất hiện lại ở đây. Đối với số sê-ri ... Seagate chỉ cung cấp các công cụ Windows. Trên linux tôi sẽ thử một inqlệnh - có lẽ từ một số trình điều khiển EMC (nên có thể tải xuống miễn phí) - nhưng đây chỉ là dự đoán.
Nils

2
@OleTange RE: "Làm cách nào để tìm số sê-ri bằng GNU / Linux trên các đĩa đang sản xuất?" chạy dmidecodenày sẽ kéo mô tả của các thành phần phần cứng từ bộ nhớ. Thông thường đối với các mặt hàng ở cấp độ người tiêu dùng, bạn sẽ không có các mục cho ổ đĩa cứng SN, nhưng, với thiết bị dành cho doanh nghiệp, thông thường sẽ có thêm mục này hoặc các ổ đĩa sẽ có nhiều thông minh hơn. Có các --typemã đặc biệt để chỉ các thiết bị MFR nếu chúng có sẵn. Các công ty cung cấp mảng thường cung cấp thông tin này để có thể định vị các ổ đĩa bị thu hồi.
2bc

@LinuxlyChallenged dmidecodethấy không có ổ đĩa - không bên trong cũng như bên ngoài. Tôi không thể tìm thấy inqDebian.
Ole Tange

@OleTange sử dụng smartctlxem câu trả lời được cập nhật của tôi ...
Nils

2

Bạn đã thử thay đổi lịch trình I / O của mình chưa?

   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 

Mặc định là CFQ thường cho hầu hết các hệ thống "hiện tại."

Để so sánh lịch trình I / O, hãy làm như sau:

Đọc thử nghiệm:

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

Điều này sẽ đảm bảo bạn đang kiểm tra đĩa và không lưu các trang RAM, điều này sẽ xóa bộ đệm.

Viết thử nghiệm:

Sao chép các tập tin của bạn nhiều lần cùng một lúc. Sau khi viết xong, vấn đềsync

Nếu bạn đang kiểm tra cả bạn có thể muốn drop_cachesvà gọi synckhi sao chép xong. Ngoài bộ lập lịch còn có các bộ điều chỉnh cho mỗi bộ lập lịch. Nhưng, một bài kiểm tra nhanh sẽ là thay đổi lịch trình và thử lại. Nếu bạn có một bộ điều khiển tốt noopsẽ giảm tải "Lập kế hoạch I / O" cho nó và không thực hiện bất kỳ lập lịch dữ liệu cấp hệ điều hành nào.

Dù sao, nó cũng đáng để thử và chỉ mất một lần echođể đặt lại.


Xem câu hỏi cập nhật cho kết quả.
Ole Tange

2

Tôi đã giải quyết vấn đề bằng cách mua thẻ SAS2008. Nó vẫn phàn nàn một chút trong nhật ký, nhưng nó không bao giờ chặn I / O của đĩa. Ngoài ra tôi đã thử nghiệm nó hỗ trợ ổ đĩa SATA 4 TB, trong khi LSI-SAS1068E chỉ hỗ trợ 2 TB.

Vì tôi sẽ trả lại LSI-SAS1068E cho người bán, tôi sẽ không thể thử các đề xuất khác. Vì vậy, tôi đóng câu hỏi ở đây.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.