Giải mã các tin nhắn nhật ký hệ thống mpt2sas tiếp tục


15

Tóm lược

Tôi đã nhận được các tin nhắn khó hiểu này trong syslog kể từ khi tôi cài đặt một số phần cứng mới và tôi không thể tìm ra vấn đề là gì, nếu nó nghiêm trọng hoặc phải làm gì với nó.

Họ đến từ HBA SATA mới và họ theo một mô hình. Tôi sẽ nhận được một số tin nhắn đầu tiên theo sau là một vài tin nhắn thứ hai 5-30 giây sau. Chúng xuất hiện trong các đốm màu được ghi lại trong cùng một giây và số lượng chính xác của mỗi loại khác nhau trong khoảng từ 2 đến 35. Có thể là vài phút hoặc vài giờ giữa các lần xuất hiện của các mục.

Ví dụ về hai thông điệp:

Jul 13 06:06:23 durandal kernel: [366918.435596] mpt2sas0: log_info(0x31120303): originator(PL), code(0x12), sub_code(0x0303)
Jul 13 06:06:28 durandal kernel: [366923.145524] mpt2sas0: log_info(0x31110d01): originator(PL), code(0x11), sub_code(0x0d01)

Nó luôn luôn là 0x31120303 theo sau là 0x31110d01.

mpt2sas là trình điều khiển cho bộ điều hợp bus máy chủ SATA tôi đang sử dụng nhưng nội dung lỗi quá khó hiểu. Nó không cho tôi biết vấn đề là gì, đĩa hoặc cổng đó là gì hoặc mức độ nghiêm trọng của nó.

Phần cứng

Supermicro X9SCL với Xeon E3-1220 và 8GB RAM.

LSI SAS2008 dựa trên Supermicro AOC-USAS2-L8I SAS / SATA HBA được kết nối với bộ khay đĩa Supermicro CSE-M35T-1B . Nó có ba Western Digital WD30EZRX và hai Segate ST3000DM001 được cắm vào nó. Tất cả các ổ đĩa 3TB (chính xác cùng số lượng ngành). Không có cổng mở rộng sử dụng.

HBA, khay đĩa và 4 ổ đĩa là mới. Một trong những chiếc WD30EZRX đã hoạt động được vài tháng, không có vấn đề gì với nó. Nếu nó được kết nối với bộ điều khiển Intel tích hợp Intel trước đó, hãy chuyển nó vào khoang ổ đĩa với thiết lập mới này.

Có vấn đề với HBA cần phải thiết lập lại thường xuyên và có hiệu suất thực sự khủng khiếp. Đã cập nhật firmware / bios thành "Giai đoạn 12", bản phát hành mới nhất có sẵn từ Supermicro và đã thay đổi loại thành CNTT (tức là thông qua, từ IR cho cuộc đột kích tích hợp kể từ khi tôi sẽ sử dụng tất cả các cuộc đột kích phần mềm): 2008IT12.FW. Bản cập nhật đó đã xóa tất cả các vấn đề ban đầu và tôi đã không bắt đầu nhận được các tin nhắn trên cho đến sau này (xem bên dưới).

Bốn đĩa đầu tiên tôi đã thêm đều nằm trên cổng SFF-8087 đầu tiên (tách thành 4 cáp SATA). Đĩa mới nhất tôi đã thêm là trên cổng khác, nếu đó là vấn đề.

Đĩa duy nhất khác trên hệ thống chứa HĐH và là ổ SSD Intel 80GB cũ hơn được cắm vào bộ điều khiển SATA tích hợp.

Phần mềm

Ubuntu 11.10 (một chiều). Linux 3.0.0-14-máy chủ x86_64. Sử dụng trình điều khiển mpt2sas đi kèm với HĐH.

Cố gắng xây dựng một mảng RAID6 bằng Linux md với năm đĩa đó. Bắt đầu với một mảng suy biến gồm 3 đĩa, hai Segate và một trong các ổ WD mới. Điều này rất nhanh và diễn ra rất tốt, không có tin nhắn nào trong nhật ký sau khi tôi cập nhật firmware. Trong khi đó, tôi vẫn đang sử dụng đĩa WD cũ trên cổng 0 của cùng một bộ điều khiển.

Đã thêm đĩa WD mới khác vào mảng. Rebuild bắt đầu và bây giờ tôi nhận được những tin nhắn đó trong syslog theo định kỳ. Tôi không chắc sẽ mất bao lâu để thêm một đĩa vào mảng nhưng thời gian ước tính (cat / Proc / mdstat) dao động từ hàng ngàn đến hàng chục nghìn phút, lâu hơn nhiều so với 3 đĩa đầu tiên. Tôi hiểu rằng các đĩa WD chậm hơn nhiều; Tôi có các mô hình khác nhau để giảm khả năng bị hỏng đĩa và đó là hai mô hình 3TB rẻ nhất.

Ghi chú

SMART không báo cáo bất kỳ vấn đề nào trên bất kỳ đĩa nào. Không có lỗi đăng nhập trên bất kỳ đĩa nào và không có thống kê lỗi nào ở bất kỳ đâu gần ngưỡng.

Các thông điệp được ghi lại chỉ bắt đầu xuất hiện sau khi tôi thêm đĩa cuối cùng, điều này cho thấy rằng một người có thể đang gặp vấn đề nhưng tôi không có gì khác chỉ vào đó.

Tôi đã tìm thấy một tệp tiêu đề dường như tương ứng với các thông điệp đăng nhập từ trình điều khiển này. Thông báo đầu tiên dường như là hủy bỏ (mã 12) cho "mã phụ" 0303 không được liệt kê. Thông báo thứ hai là thiết lập lại (mã 11) vì một lý do không rõ ràng. Nếu tôi có thể xác định 0303 và 0d01 có nghĩa là gì, điều đó sẽ thực sự hữu ích.

Tôi biết rằng 4 đĩa trong RAID6 5 đĩa là một mảng không hoàn chỉnh. Tôi dự định sao chép nội dung của đĩa cũ vào mảng sau khi hoàn thành việc tích hợp đĩa thứ 4 và sau đó thêm đĩa cũ vào mảng.

Câu trả lời:


5

Có khả năng đặt cược tốt nhất của bạn là một vấn đề phần cứng ở đâu đó giữa các đĩa của bạn và lên đến và bao gồm cả bộ điều khiển đột kích sas của bạn. Tôi khuyên bạn nên thử:

  1. Chạy bất kỳ công cụ chẩn đoán nào từ nhà cung cấp nếu chúng có sẵn
  2. Kiểm tra / tái đặt / thay thế cáp
  3. loại bỏ các thành phần phần cứng và trao đổi phần cứng trong chuỗi kết nối các đĩa với bộ điều khiển đột kích của bạn, bao gồm cả bộ điều khiển (nghĩa là, đối với bạn, hãy thử một cái gì đó khác ngoài cuộc đột kích tích hợp bo mạch chủ).

Tôi đã có một trong hai Dell PowerEdge R515 giống hệt nhau cho các thông báo rất giống nhau (nhật ký điền đầy đủ các tin nhắn mpt2sas0, mặc dù tôi không có mã số chính xác). Chẩn đoán khả năng khởi động của Dell đã chọn những lỗi này là "lỗi phần cứng" và thay thế bảng nối đa năng RAID đã giải quyết vấn đề.

Khi tôi đang điều tra, tôi không thể tìm thấy một nguồn tài nguyên toàn diện về các mã lỗi mpt2sas0 khác nhau có nghĩa là gì. Tôi nghi ngờ họ thậm chí có thể là nhà cung cấp phần cứng cụ thể (ai đó biết nhiều hơn về SAS cần xác nhận hoặc từ chối điều này). Vì vậy, mã lỗi của bạn có thể có nghĩa là một cái gì đó khác biệt rộng rãi, nhưng nếu SMART sạch sẽ, thật khó để tưởng tượng những lý do tốt khác để mpt2sas0 báo cáo mã lỗi.

Những lỗi này có thể rất nghiêm trọng. R515 của tôi hoạt động có vẻ ổn với các tin nhắn này trong một tuần với phần mềm Ubuntu Linux 12 đĩa đột kích 6, nhưng sau đó đột nhiên đẩy tất cả 12 đĩa ra khỏi mảng bị hỏng (!)

Ngoài ra trong trường hợp của tôi, SMART cho tất cả các đĩa đã hoàn toàn sạch. Kiểm tra tốt là kiểm tra tự chẩn đoán thông minh : smartctl -t long /dev/sdX, và sau đó kiểm tra kết quả về một ngày sau đó với smartctl -l selftest /dev/sdX. Nếu tất cả đều ổn, bài kiểm tra sẽ nói CompletedLBA_first_errcột sẽ trống.


Lưu ý: bộ điều khiển RAID (HBA thực sự) đã là một thẻ riêng. Bộ điều khiển SATA trên bo mạch hoạt động tốt. Tôi có một cáp SFF-8087 thay thế theo đơn đặt hàng, sẽ có mặt ở đây vào ngày mai. Đó là nghi ngờ hàng đầu của tôi tại thời điểm này.
Chris Smith

Cáp xấu là vấn đề! Tôi đã thay thế cả hai (hai cổng SFF) bằng một số cáp chất lượng cao hơn và không gặp vấn đề gì kể từ đó! Tôi chấp nhận câu trả lời của bạn vì đây là câu hỏi dài nhất và không có dây cáp xấu. PS Tôi chắc chắn đã làm các bài kiểm tra SMART dài; không có vấn đề trên bất kỳ đĩa nào.
Chris Smith

Thật tuyệt khi nghe rằng bạn đã tìm thấy vấn đề. Cảm ơn đã chấp nhận.
Rickard Armiento

Đối với tôi thực sự kỳ lạ khi tôi gặp vấn đề này trước đây cũng chỉ trong trường hợp nền tảng Dell PowerEdge. Kết quả tương tự là vấn đề với dây cáp ...
Mazeryt

3

Wow, một khó khăn.

Điều này dường như chỉ ra rằng 0x31120303 là thiết lập lại bus do một trong các thiết bị của bạn đang tải nặng. Nó cũng nói rằng bạn không cần phải lo lắng về nó. (Haha, đúng rồi.)

Điều này cho thấy rằng các thông báo nhật ký này đang xảy ra do một trong các thiết bị của bạn mất quá nhiều thời gian để trả lời các lệnh. Điều này nói điều tương tự, và cũng chỉ ra nó xảy ra dưới tải nặng.

Mặc dù đây không phải là một câu trả lời hoàn chỉnh, nhưng nó hy vọng sẽ chỉ cho bạn một hướng hữu ích.


Tôi đã thấy một số bài đăng đó nhưng không bao giờ có thể tìm thấy thông điệp chính xác đang nhận được. Hóa ra là cáp SFF-8087-> xấu. Cảm ơn đã giúp đỡ!
Chris Smith

0

Điều này có nghĩa là bạn có một số lỗi trên đĩa, đó là đĩa SATA trong bộ điều khiển SAS từ LSI và do lỗi, tất cả các yêu cầu chưa xử lý đã bị hủy bỏ.

Trong hầu hết các trường hợp, bạn có một lỗi trung bình trên đĩa là nguyên nhân gây ra lỗi này. Bản thân lỗi này không có nghĩa là lỗi trung bình và bạn sẽ cần kiểm tra nhật ký để biết các gợi ý khác để tìm nguồn gốc của lỗi đĩa gốc.

Phiên bản công phu hơn một chút tại: http://blog.disksurvey.org/blog/2014/03/27/sata-handling-of-medium-errors-log-info-0x0x 31080000/


Bài viết thú vị, cảm ơn đã chia sẻ! SATA là một giao thức crappy nhưng các đĩa rẻ và làm những gì tôi cần. Tin nhắn đã không xuất hiện lại kể từ khi tôi thay thế cáp bị lỗi.
Chris Smith

1
Có thể tìm thấy thêm giải mã LSI Loginfo thông qua một tiện ích tôi đã tạo để giải mã nó: blog.disksurvey.org/blog/2014/08/10/decoding-lsi-loginfo-codes
Baruch Ngay cả
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.