Dmesg đầy lỗi I / O, thông minh ok, bốn đĩa bị ảnh hưởng


8

Tôi đang làm việc trên một máy chủ từ xa (Dell Poweredge) là một bản cài đặt mới. Nó có bốn ổ đĩa (2TB) và 2 ổ SSD (250 GB). Một ổ SSD chứa HĐH (RHEL7) và bốn đĩa cơ học cuối cùng sẽ chứa cơ sở dữ liệu orory.

Cố gắng tạo một mảng RAID phần mềm dẫn đến các đĩa liên tục bị đánh dấu là bị lỗi. Kiểm tra dmesg đưa ra một loạt các lỗi sau,

[127491.711407] blk_update_request: I/O error, dev sde, sector 3907026080
[127491.719699] sd 0:0:4:0: [sde] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127491.719717] sd 0:0:4:0: [sde] Sense Key : Aborted Command [current]
[127491.719726] sd 0:0:4:0: [sde] Add. Sense: Logical block guard check failed
[127491.719734] sd 0:0:4:0: [sde] CDB: Read(32)
[127491.719742] sd 0:0:4:0: [sde] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127491.719750] sd 0:0:4:0: [sde] CDB[10]: e8 e0 7c a0 e8 e0 7c a0 00 00 00 00 00 00 00 08
[127491.719757] blk_update_request: I/O error, dev sde, sector 3907026080
[127491.719764] Buffer I/O error on dev sde, logical block 488378260, async page read
[127497.440222] sd 0:0:5:0: [sdf] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127497.440240] sd 0:0:5:0: [sdf] Sense Key : Aborted Command [current]
[127497.440249] sd 0:0:5:0: [sdf] Add. Sense: Logical block guard check failed
[127497.440258] sd 0:0:5:0: [sdf] CDB: Read(32)
[127497.440266] sd 0:0:5:0: [sdf] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127497.440273] sd 0:0:5:0: [sdf] CDB[10]: 00 01 a0 00 00 01 a0 00 00 00 00 00 00 00 00 08
[127497.440280] blk_update_request: I/O error, dev sdf, sector 106496
[127497.901432] sd 0:0:5:0: [sdf] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127497.901449] sd 0:0:5:0: [sdf] Sense Key : Aborted Command [current]
[127497.901458] sd 0:0:5:0: [sdf] Add. Sense: Logical block guard check failed
[127497.901467] sd 0:0:5:0: [sdf] CDB: Read(32)
[127497.901475] sd 0:0:5:0: [sdf] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127497.901482] sd 0:0:5:0: [sdf] CDB[10]: e8 e0 7c a0 e8 e0 7c a0 00 00 00 00 00 00 00 08
[127497.901489] blk_update_request: I/O error, dev sdf, sector 3907026080
[127497.911003] sd 0:0:5:0: [sdf] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127497.911019] sd 0:0:5:0: [sdf] Sense Key : Aborted Command [current]
[127497.911029] sd 0:0:5:0: [sdf] Add. Sense: Logical block guard check failed
[127497.911037] sd 0:0:5:0: [sdf] CDB: Read(32)
[127497.911045] sd 0:0:5:0: [sdf] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127497.911052] sd 0:0:5:0: [sdf] CDB[10]: e8 e0 7c a0 e8 e0 7c a0 00 00 00 00 00 00 00 08
[127497.911059] blk_update_request: I/O error, dev sdf, sector 3907026080
[127497.911067] Buffer I/O error on dev sdf, logical block 488378260, async page read

Những lỗi này xảy ra đối với tất cả bốn đĩa cơ, (sdc / sdd / sde / sdf) SMARTctl đã vượt qua cả bốn đĩa, các bài kiểm tra dài và ngắn. Tôi hiện đang chạy badblocks (kiểm tra chế độ ghi ~ 35 giờ, có thể là 35 giờ nữa).

Sau đây là những lỗi tôi nghi ngờ / xem xét khi nghiên cứu

  • Ổ cứng bị lỗi - Có vẻ như 4 đĩa "được tân trang" không phải là DOA phải không?

  • Sự cố bộ điều khiển lưu trữ (cáp xấu?) - Có vẻ như nó cũng sẽ ảnh hưởng đến SSD?

    • Vấn đề về hạt nhân, Sự thay đổi duy nhất đối với kernel stock là việc thêm kmod-oracleasm. Tôi thực sự không thấy nó sẽ gây ra những lỗi này như thế nào, ASM hoàn toàn không được thiết lập.

Một sự kiện đáng chú ý khác là khi cố gắng zero các đĩa (một phần của khắc phục sự cố sớm), sử dụng lệnh $ dd if = / dev / zero of = / dev / sdX đã gây ra các lỗi này,

dd: writing to ‘/dev/sdc’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.70583 s, 32.0 MB/s
dd: writing to ‘/dev/sdd’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.70417 s, 32.0 MB/s
dd: writing to ‘/dev/sde’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.71813 s, 31.7 MB/s
dd: writing to ‘/dev/sdf’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.71157 s, 31.9 MB/s

Nếu bất cứ ai ở đây có thể chia sẻ một số cái nhìn sâu sắc về những gì có thể gây ra điều này, tôi sẽ biết ơn. Tôi có xu hướng theo dõi dao cạo của thỉnh thoảng ở đây và đi thẳng vào ổ cứng, sự nghi ngờ duy nhất bắt nguồn từ việc không có bốn ổ cứng bị hỏng.

Tôi sẽ lái xe đến trang web vào ngày mai để kiểm tra thực tế & báo cáo đánh giá của tôi về máy này cho các cấp cao hơn. Nếu có thứ gì đó tôi nên kiểm tra thực tế (ngoài cáp / kết nối / nguồn điện) xin vui lòng cho tôi biết.

Cảm ơn.


Khi bạn nói SMART "ok", bạn có nghĩa là sức khỏe tổng thể? Có bất kỳ bộ đếm thô riêng lẻ nào cho các khu vực được phân bổ lại hoặc đang chờ xử lý khác không? Ổ đĩa không ngay lập tức tuyên bố thất bại trên khu vực xấu đầu tiên, mặc dù nó không thể đọc được. Sử dụng smartctl -x /dev/sdahoặc một cái gì đó. Nhưng điều đáng nghi ngờ là đó là cùng một LBA trên tất cả các đĩa.
Peter Cordes

Câu trả lời:


14

Các ddthử nghiệm của bạn cho thấy tất cả bốn đĩa đều thất bại tại cùng một địa chỉ LBA . Vì rất khó có khả năng bốn đĩa đều bị lỗi tại cùng một vị trí, tôi rất nghi ngờ đó là do vấn đề của bộ điều khiển hoặc hệ thống cáp.


1
Thật khó để nói mà không thử nghiệm thêm. Dù sao, suy nghĩ đầu tiên tôi sẽ điều khiển / thay thế là dây cáp gắn bộ điều khiển vào bảng nối đa năng.
shodanshok

4
Cáp tốc độ dữ liệu cao, như 6/12 Gbs SATA / SAS, không chỉ về tính liên tục điện, mà chủ yếu là về độ rõ của tín hiệu và độ nhiễu thấp. Cố gắng làm sạch vật lý các đầu nối và nối lại dây cáp. Nếu lỗi vẫn còn, hãy thử thay đổi chúng và cuối cùng, hãy thử một bộ điều khiển khác.
shodanshok

2
Cùng một LBA dường như không phải là một vấn đề cáp. Trừ khi dữ liệu trong khu vực đó xảy ra là một chuỗi bit trong trường hợp xấu nhất đối với một số sự xáo trộn (để ngăn chặn các hoạt động kéo dài của đồng hồ tự hủy hoàn toàn bằng không) hoặc ECC qua liên kết SATA / SAS. Tôi không chắc chắn mã hóa mà liên kết sử dụng. Bộ điều khiển là hợp lý mặc dù; cùng một LBA trên mỗi đĩa cần một số loại giải thích yếu tố chung.
Peter Cordes

3
@ djsmiley2k Thật khó khăn khi cả bốn ddkết thúc bộ nhớ cache trên cùng một địa chỉ RAM đều bị lỗi. Hơn nữa, DRAM của PERC được bảo vệ ECC và trong khi RAM ECC cũng bị lỗi, điều này tương đối không phổ biến. Điều đó nói rằng, bộ điều khiển có thể là nguồn gốc của các vấn đề, vì vậy, nếu việc thay đổi dây cáp không có ích, OP nên thử đổi bộ điều khiển.
shodanshok

2
Vâng, các bạn của tôi, bạn đã đúng. Cáp + bộ điều khiển đã hoán đổi và giờ là 600GB trong quy trình xử lý dd và không có lỗi cho đến nay. Có vẻ như mọi thứ đang hoạt động chính xác. Cảm ơn một lần nữa cho tất cả các kiến ​​thức bạn đã chia sẻ. Tôi luôn biết ơn cộng đồng này về chuyên môn và sự sẵn sàng chia sẻ nó. :)
Scu11y
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.