Ổ cứng đọc lỗi mà lỗi dừng?


10

Câu chuyện của tôi bắt đầu khá đơn giản. Tôi có một máy chủ hoạt động nhẹ, chạy Arch Linux, nơi lưu trữ hầu hết dữ liệu của nó trên RAID-1 gồm hai ổ đĩa SATA. Nó đã hoạt động mà không có bất kỳ vấn đề trong khoảng 4 tháng. Sau đó, đột nhiên tôi bắt đầu nhận được lỗi đọc trên một trong các ổ đĩa. Luôn luôn, các tin nhắn trông rất giống như thế này:

Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT
Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in
Apr 18 00:20:15 hope kernel: [307085.582050]          res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error)
Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR }
Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC }
Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code
Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd]  Sense Key : Medium Error [current] [descriptor]
Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex):
Apr 18 00:20:15 hope kernel: [307085.641001]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Apr 18 00:20:15 hope kernel: [307085.641010]         27 34 6a 0c 
Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd]  Add. Sense: Unrecovered read error - auto reallocate failed
Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00
Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444
Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete
Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1)
Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1

Mỗi lỗi phàn nàn về một số khu vực khác nhau và đi kèm với độ trễ vài giây cho người dùng (tôi) truy cập vào đĩa.

Tôi đã kiểm tra đầu ra smartctl và thấy đầu ra sau (các phần không liên quan được cắt bớt):

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       51

Nhìn lại nhật ký, tôi thấy rằng các lỗi thực sự đã xảy ra trong vài ngày, chủ yếu là trong các bản sao lưu, nhưng cũng thường xuyên trong quá trình sử dụng rất nhẹ (nghĩa là cứ sau 5 lần tôi cố lưu tệp văn bản). Tôi kết luận rằng đĩa của tôi sắp chết, RAID-1 đang xử lý nó một cách thích hợp và đã đến lúc đặt mua một đĩa thay thế. Tôi đã đặt một đĩa mới.

Thật ngạc nhiên, một ngày sau, các lỗi ... dừng lại. Tôi đã không làm gì để sửa chúng. Tôi đã không khởi động lại, đã không lấy ổ đĩa ngoại tuyến, không có gì. Nhưng các lỗi chỉ dừng lại.

Vào thời điểm đó, tò mò muốn xem liệu các thành phần xấu hiện chỉ nằm trong các phần nhàn rỗi của đĩa, tôi đã lấy đĩa ra khỏi RAID, đặt lại vào RAID và cho phép nó hoàn thành việc đồng bộ lại đầy đủ. Đồng bộ hóa hoàn thành mà không có bất kỳ lỗi nào, 9 giờ sau (đĩa 2TB mất một chút thời gian).

Ngoài ra, đầu ra smartctl đã thay đổi một chút, như sau:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       43
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       38
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0

Vì vậy, phần của điều này khiến chúng tôi ngạc nhiên là, tất nhiên, "Từ khi nào các đĩa xấu tự khắc phục?"

Tôi cho rằng có thể một khu vực rất nhỏ của ổ đĩa bị hỏng một cách tự nhiên và ổ đĩa chỉ mất 3 ngày (!) Trước khi mã phân bổ lại khu vực của nó khởi động và nó ánh xạ một số khu vực dự phòng trên một khu vực xấu của đĩa ... Nhưng tôi không thể nói rằng tôi đã từng thấy điều đó xảy ra.

Có ai khác nhìn thấy loại hành vi này? Nếu vậy, kinh nghiệm của bạn với ổ đĩa sau đó là gì? Nó đã xảy ra một lần nữa? Đĩa cuối cùng đã thất bại hoàn toàn? Hay đó chỉ là một trục trặc không giải thích được mà vẫn không giải thích được?

Trong trường hợp của tôi, tôi đã có ổ đĩa thay thế (được bảo hành), vì vậy có lẽ tôi sẽ chỉ thay thế ổ đĩa. Nhưng tôi rất muốn biết nếu tôi chẩn đoán sai điều này bằng cách nào đó. Nếu nó giúp, tôi đã hoàn thành đầu ra 'smartctl -a' từ khi sự cố xảy ra. Nó chỉ hơi dài, vì vậy tôi đã không đăng nó ở đây.


Kiểu dáng & mô hình của ổ đĩa là gì?
Antonius Bloch

Đó là ổ đĩa 2TB Western Digital Caviar Black, model WD2001FAAS. Tôi biết, không chính xác là một đĩa cấp máy chủ, nhưng nó cũng không hẳn là một máy chủ cấp sản xuất trung tâm dữ liệu.
Rick Koshi

Câu trả lời:


9

Nếu một vùng vật lý cụ thể của bề mặt ổ đĩa bị hỏng, thì cho đến khi các thành phần đó có thể được ánh xạ thành công, bạn sẽ nhận được các lỗi đọc không được phục hồi khi bạn cố đọc bất kỳ dữ liệu nào được ghi vào vùng đó. Ổ đĩa biết rằng các khu vực là xấu (sau khi không thể truy cập vào các lĩnh vực) nhưng không thể ánh xạ lại các lĩnh vực vì họ đã giữ dữ liệu. Nếu bạn định dạng ổ đĩa hoặc ghi đè lên các thành phần "xấu", thì ổ đĩa sẽ có cơ hội vạch ra các khu vực xấu.

Khi các thành phần xấu được lập bản đồ và miễn là bề mặt ổ đĩa không bị hỏng, bạn sẽ ở trạng thái tốt.

Tôi không biết đủ về các mô hình lỗi ổ đĩa của các ổ đĩa hiện tại để biết liệu có nhiều mối tương quan giữa một phần của bề mặt phương tiện bị hỏng và sự cố lan rộng hoặc xảy ra lần nữa hay không. Nếu không có mối tương quan, thì một khi các thành phần xấu được vạch ra, bạn đang ở trong tình trạng tốt. Nếu có một mối tương quan, thì đây là sự khởi đầu của sự kết thúc của ổ đĩa.


4

Hầu hết các ổ đĩa hiện đại sẽ "véc tơ" một khối đã bị hỏng. Ổ đĩa có một khối các khối dự phòng và phần sụn sử dụng các khối này để thay thế bất kỳ khối nào được biết là ổ đĩa bị hỏng. Ổ đĩa không thể thực hiện việc ánh xạ lại này khi nó không đọc được một khối vì nó không thể cung cấp dữ liệu chính xác. Nó chỉ trả về "lỗi đọc". Nó đánh dấu khối là xấu, vì vậy nếu khối nào đọc đúng thì khối đó được vectơ ra và dữ liệu chính xác được ghi vào khối thay thế. Nếu HĐH đã VIẾT cho một khối ở trạng thái "vectơ đang chờ xử lý" thì khối đó được vectơ ra và dữ liệu được ghi vào khối thay thế.

Cuộc đột kích phần mềm Linux, khi nhận được lỗi đọc từ thiết bị, sẽ nhận được dữ liệu chính xác từ các thành phần khác trong mảng và sau đó nó cố gắng VIẾT lại khối xấu. Vì vậy, nếu ghi hoạt động tốt thì dữ liệu vẫn an toàn, nếu không, ổ đĩa chỉ thực hiện như trên, vectơ khối và sau đó thực hiện ghi. VÌ VẬY, ổ đĩa có, với sự trợ giúp của hệ thống đột kích, chỉ cần tự sửa chữa!

Giả sử các sự kiện như vậy là rất hiếm, có lẽ là an toàn để tiếp tục. Nếu quá nhiều khối thay thế đang được sử dụng thì ổ đĩa có thể có vấn đề. Có giới hạn về số lượng khối thay thế có thể được chuyển sang các khối dự phòng và đó là chức năng của ổ đĩa.


3

Vâng, tôi đã thấy điều này là tốt, và trong những trường hợp rất giống nhau. Trong trường hợp của tôi, đó là ổ đĩa "Green" 1TB "xanh" cấp độ người tiêu dùng (WD10EARS) đã kéo tôi đóng thế. Current_Pending_SectorGiá trị thô SMART đã tăng từ 0 đến 6, rồi 8, nhắc daemon giám sát SMART gửi cho tôi một số email đáng ngại.

Tôi mdadm --failed và --removed ổ đĩa từ mảng và chạy một đường chuyền không phá hủy của badblockstrên nó, và có, rõ ràng là đã có hơn 2 chục khối xấu. Khi ổ đĩa thay thế đến khoảng một ngày sau đó, tôi đã sửa lỗi mảng và cuộc sống vẫn tiếp tục.

Không lâu sau đó, vì chán nản, tôi chạy xe badblocksvào "thất bại" để xem nó có xấu đi không. Ngược lại, ổ đĩa đã hoàn toàn "sửa chữa": không có khối xấu! Lắc đầu, tôi lau nó và đặt nó sang một bên để được tái chế hoặc tặng.

Bài học: Đừng sử dụng các ổ đĩa cấp độ người tiêu dùng trong các máy chủ, trừ khi bạn sẵn sàng và có thể đưa ra tất cả các cách kỳ lạ và không đáng tin cậy. Hệ quả: Đừng bỏ tiền ra trên các thành phần máy chủ, vì cuối cùng bạn sẽ trả tiền cho chúng, trong thời gian thêm và làm nặng thêm.


Nếu tất cả các khối xấu được tìm thấy đều được lập bản đồ thành công và không có lĩnh vực bổ sung nào bị hỏng, thì kết quả của bạn là những gì bạn mong đợi sẽ thấy. Đoạn cuối của bạn vẫn là câu trả lời đúng.
Eddie

0

Đó là thực tế phổ biến trong môi trường máy chủ để loại bỏ các ổ đĩa từng có lỗi như vậy, đã sửa hay chưa. Lỗi cứng của ngành có thể là dấu hiệu của sự phá hủy bề mặt vật lý đối với môi trường - và nếu bạn làm trầy xước bề mặt, bạn thường di chuyển vật liệu sang các mặt của vết xước và có độ vênh cao hơn mặt phẳng của bề mặt đó - hoặc bụi mài mòn (thủy tinh! ). Cả hai đều có xu hướng gây hại cho hệ thống cơ học dựa trên đệm không khí rất mỏng giữa hai bề mặt được cho là hoàn toàn trơn tru ... đó là lý do tại sao các lỗi trung bình một khi chúng bắt đầu đạt đến một số lượng nhất định có xu hướng nhân lên nhanh hơn.

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.