내 이야기는 아주 간단하게 시작됩니다. Arch Linux를 실행하는 가벼운 서버가 있는데, 대부분의 데이터를 두 개의 SATA 드라이브로 구성된 RAID-1에 저장합니다. 약 4 개월 동안 아무런 문제없이 작동했습니다. 그런 다음 갑자기 드라이브 중 하나에서 읽기 오류가 발생하기 시작했습니다. 항상 메시지는 다음과 같이 많이 보입니다.
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
각 오류는 다른 섹터 번호에 대해 불평했고 디스크에 액세스하는 사용자 (me)에 대해 몇 초의 지연이 수반되었습니다.
smartctl 출력을 확인하고 다음과 같은 출력을 보았습니다 (관련 부품이 잘리지 않음).
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
로그를 되돌아 보면 오류가 실제로 며칠 동안, 주로 백업 중에 발생하지만 매우 가벼운 사용 중에 (텍스트 파일을 저장하려고 할 때마다 약 5 회마다) 발생하는 것을 발견했습니다. 디스크가 죽어 가고 RAID-1이 디스크를 적절하게 처리하고 있으며 교체 디스크를 주문할 때라고 결론을 내 렸습니다. 새 디스크를 주문했습니다.
놀랍게도, 하루 후, 오류는 … 중지되었습니다. 나는 그들을 고치기 위해 아무것도하지 않았다. 나는 재부팅하지 않았고 드라이브를 오프라인으로 만들지 않았습니다. 그러나 오류는 막을 내렸다.
이 시점에서 불량 섹터가 디스크의 유휴 부분에 있는지 궁금한 점이 궁금합니다. RAID에서 디스크를 꺼내 RAID에 다시 넣은 다음 전체 재 동기화를 완료 할 수있었습니다. 재 동기화는 9 시간 후에 오류없이 완료되었습니다 (2TB 디스크는 시간이 조금 걸립니다).
또한 smartctl 출력은 다음과 같이 약간 변경되었습니다.
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
그래서, 이상하게 여기는 부분은 “나쁜 디스크는 언제부터 스스로를 고치는가?”입니다.
드라이브의 아주 작은 영역이 자발적으로 나빠질 수 있고 섹터 재 할당 코드가 시작되기 전에 드라이브가 3 일 (!) 걸렸고 디스크의 나쁜 영역에 일부 예비 섹터를 매핑했다고 가정합니다 … 그러나 나는 그것이 일어난 것을 본 적이 없다.
다른 사람이 이런 종류의 행동을 본 적이 있습니까? 그렇다면 그 드라이브에 대한 경험은 어떠 했습니까? 다시 일어 났습니까? 디스크가 결국 완전히 실패 했습니까? 아니면 설명 할 수없는 채로 남아있는 설명 할 수없는 결함일까요?
제 경우에는 이미 교체 드라이브 (보증서에 따름)가 있으므로 어쨌든 드라이브를 교체 할 것입니다. 그러나 내가 어떻게 든 이것을 잘못 진단했는지 알고 싶습니다. 도움이된다면 문제가 발생했을 때의 ‘smartctl -a’출력이 완료되었습니다. 조금 길어서 여기에 게시하지 않았습니다.
답변
드라이브 표면의 특정 물리적 영역이 잘못되면 해당 섹터를 성공적으로 매핑 할 수있을 때까지 해당 영역에 기록 된 데이터를 읽으려고하면 복구되지 않은 읽기 오류가 발생합니다. 드라이브는 섹터에 액세스하지 못한 후 섹터가 불량하지만 이미 데이터를 보유하고 있으므로 섹터를 다시 맵핑 할 수 없음을 알고 있습니다. 드라이브를 포맷하거나 “불량”섹터를 덮어 쓰면 드라이브가 불량 섹터를 매핑 할 수 있습니다.
불량 섹터가 매핑되고 더 많은 드라이브 표면이 고장 나지 않는 한 양호한 상태입니다.
미디어 드라이브의 한 부분이 나 빠지고 문제가 확산되거나 다시 발생하는 문제 사이에 많은 상관 관계가 있는지 알기 위해 현재 드라이브의 드라이브 오류 모델에 대해 충분히 알지 못합니다. 상관 관계가없는 경우 불량 섹터가 매핑되면 올바른 모양입니다. 상관 관계 가 있는 경우 이는 드라이브 끝의 시작입니다.
답변
대부분의 최신 드라이브는 불량 블록을 “벡터화”합니다. 드라이브에는 예비 블록 풀이 있으며 펌웨어는이를 사용하여 드라이브에 알려진 것으로 알려진 블록을 교체합니다. 드라이브는 올바른 데이터를 제공 할 수 없기 때문에 블록을 읽지 못하면 드라이브를 다시 매핑 할 수 없습니다. “읽기 오류”만 반환합니다. 블록을 불량으로 표시하므로 블록이 올바르게 읽 히면 블록이 벡터화되고 올바른 데이터가 대체 블록에 기록됩니다. OS가 “벡터 출력 보류”상태 인 블록에 쓰면 블록이 벡터화되고 데이터가 대체 블록에 기록됩니다.
Linux 소프트웨어 RAID는 장치에서 읽기 오류가 발생하면 배열의 다른 요소에서 올바른 데이터를 가져온 다음 불량 블록을 다시 쓰려고 시도합니다. 따라서 쓰기가 정상적으로 작동하면 데이터가 안전합니다. 그렇지 않은 경우 드라이브는 위의 작업을 수행하고 블록을 벡터화 한 다음 쓰기를 수행합니다. 따라서 드라이브는 공격대 시스템의 도움으로 자체적으로 수리되었습니다!
그러한 사건이 합리적으로 드물다고 가정하면, 계속하는 것이 안전 할 것입니다. 너무 많은 교체 블록을 사용하는 경우 드라이브에 문제가있을 수 있습니다. 스페어 블록으로 벡터화 될 수있는 교체 블록 수에는 제한이 있으며 이는 드라이브의 기능입니다.
답변
예, 나는 이것도 매우 유사한 상황에서 보았습니다. 제 경우에는 “소비자 용”Western Digital 1TB “Green”드라이브 (WD10EARS)였으며 그로 인해 저를 괴롭 혔습니다. SMART Current_Pending_Sector원시 값이 0에서 6으로, 8로 증가하여 SMART 모니터링 데몬이 불길한 이메일을 보내도록 요청합니다.
나는 어레이에서 드라이브를 mdadm --fail편집하고 --remove비파괴 적 인 패스를 실행 badblocks했으며, 물론 20 개 이상의 불량 블록이있었습니다. 교체 드라이브가 약 하루 후에 도착했을 때 어레이를 고정 시켰으며 수명이 다했습니다.
그 직후, 나는 지루함 badblocks에서 “실패한”드라이브로 돌아가서 그것이 나빠 졌는지 확인했다. 반대로 드라이브는 완전히 “수리”되었습니다. 불량 블록은 없습니다! 머리를 흔들면서 머리를 닦고 재활용 또는 기증을 위해 따로 보관 해 두었습니다.
교훈 : 모든 기이함과 신뢰성을 기꺼이 감수 할 수 없다면 서버에서 소비자 용 드라이브를 사용하지 마십시오. 결론 : 결국 서버 구성 요소를 저렴하게 구매하지 마십시오. 결국 추가 시간과 악화로 인해 비용을 지불하게 될 것입니다.
답변
서버 환경에서는 이러한 오류가 수정되었거나 수정되지 않은 드라이브를 버리는 것이 일반적입니다. 섹터 하드 오류는 매체에 물리적 인 표면 손상의 징후 일 수 있습니다. 표면을 긁으면 일반적으로 재료를 스크래치의 측면으로 옮기고 표면의 평면보다 더 높은 버 또는 연마 성 먼지 (유리)가 발생합니다. ). 두 표면 사이의 매우 얇은 에어 쿠션에 의존하는 기계 시스템에 두 가지 모두 손상을주는 경향이 있습니다. 그러면 완벽하게 매끄럽게 추정됩니다. 그러므로 특정 카운트에 도달하면 중간 오차가 더 빨리 증가하는 경향이 있습니다.