Linux 디스크에서 읽을 수없는 단일 블록을 쉽게 복구하려면 어떻게합니까?


22

Linux 시스템이 syslog에 SMART 오류를 발생시키기 시작했습니다. 나는 그것을 추적하고 문제가 디스크의 단일 블록이라고 생각합니다. 디스크가 한 블록을 재 할당하도록하려면 어떻게해야합니까? 프로세스에서 어떤 파일이 손상되었는지 알고 싶습니다. (디스크에서 하나의 블록이 고장 나면 다른 블록이 뒤따를 수 있다는 것을 알고 있습니다. 백업이 잘 진행 중이며이 디스크를 계속 작동 시키려고합니다.)

웹을 검색하면 마운트 해제 된 디스크의 수동 프로세스를 설명하는 불량 블록 HOWTO 가 나타납니다. 복잡하고 오류가 발생하기 쉬운 것 같습니다. Linux에서이 프로세스를 자동화하는 도구가 있습니까? 다른 유일한 옵션은 제조업체의 진단 도구 이지만 파괴 된 내용에 대한보고없이 나쁜 블록을 방해한다고 가정합니다. 최악의 경우 파일 시스템 메타 데이터 일 수 있습니다.

해당 디스크는 기본 시스템 파티션입니다. ext3fs 및 LVM 사용 다음은 syslog의 오류 로그와 smartctl의 관련 비트입니다.

smartd[5226]: Device: /dev/hda, 1 Currently unreadable (pending) sectors

Error 1 occurred at disk power-on lifetime: 17449 hours (727 days + 1 hours)
... Error: UNC at LBA = 0x00d39eee = 13868782

pastebin에 전체 smartctl 덤프 있습니다.


디스크 펌웨어가 읽을 때 불량 블록을 자동으로 다시 매핑한다고 생각했기 때문에 이론적으로 이미 완료되었습니다. 아래에 설명 된대로, 오버레이 FS가 여전히 안정적인지 확인하려면 fsck (또는 FS에 대한 올바른 equiv)를 실행하십시오.
BuildTheRobots

2
디스크 펌웨어는 읽기가 아닌 쓰기시 에만 블록을 다시 매핑한다는 것을 이해 합니다. 따라서 실제로 해당 블록에 쓰기를 강제해야합니다.
Nelson

1
마침내이 디스크를 폐기했습니다. 몇 달 동안 정상적으로 실행되었지만 5 번째 읽기 오류 후에 포기했습니다.
Nelson

답변:


12

시도해 볼 수 hdparm --write-sector <LBA> /dev/ice있습니다.

나는 이것을하는 다른 방법을 모른다 .LBA를 파일 시스템 블록으로 수동으로 변환해야한다 (이미 찾은 것처럼)


오, 그게 새로운 깃발이야! 그것은 확실히 나쁜 블록을 재 할당 할 것입니다. 이제 필요한 것은 클로버를 찾을 수있는 쉬운 방법입니다.
Nelson

3
이 방법을 사용하여 디스크를 수정 한 후 이것이 올바른 방법이라고 말할 수 있습니다. 해당 섹터에 대한 쓰기를 강제하면 드라이브가 섹터를 향하게하고 (a) 성공적인 쓰기를 얻거나 (b) 리맵과 함께 영구적 인 불량 초로 끝납니다.
에이버리 페인

큰! 그리고보다 너무 쉽게 smartmontools.sourceforge.net/badblockhowto.html
Janning

그것은 이상한 그 간단한 유틸리티 자동화되지 않은 (SMART를 통해 다음 불량 섹터를 찾고 재 할당을 강제)이 반복되는 과정 ..!
IMZ - 이반 Zakharyaschev

32

예전에는 WD 용 디스크 펌웨어를 작성했으며 불량 블록을 다시 할당 한 펌웨어를 작성했습니다.

첫째, 대부분의 불량 블록은 쓰기가 아닌 읽기에서 감지됩니다. 쓰기는 맹목적으로 수행되므로 데이터를 확인하지 않고 기록합니다. 따라서 미디어가 나쁜 경우 쓰기에서 호스트가 해당 섹터를 읽을 때까지 알 수 없습니다. 올바른 섹터를 찾기 위해 쓰기에서 읽은 섹터의 작은 부분 (섹터 헤더)이 있으므로 섹터 헤더를 읽는 데 오류가있는 경우 드라이브가 섹터를 다시 할당하고 수신 된 데이터로 기록합니다 쓰기 명령에서. 그러나 대부분의 불량 블록은 읽기에서 감지되며, 쓰기가 섹터에 성공한다고해서 미디어가 양호하거나 섹터가 재 할당되었음을 의미하지는 않습니다.

이제 불량 블록 재 할당 (재 할당이라고도 함)에 대해 설명합니다. 그렇습니다. 일반적으로 오류가 충분히 나쁘면 (즉, ECC 오류가 충분히 나쁘면) 드라이브가 섹터를 재 할당하려고 시도하지만 ECC 수정 후에도 드라이브가 여전히 데이터를 복구 할 수 있습니다. 일반적으로이 작업은 자동으로 수행됩니다. 유일한 예외는 호스트가 이전에 드라이브에 자동 재 할당을하지 말라고 지시했을 수 있지만 거의 수행되지 않습니다.

드라이브가 데이터를 읽고 데이터를 복구 할 수 없으면 어떻게됩니까? 아무것도. 오류는 호스트에보고되지만 재 할당은 수행되지 않습니다. 문제는 드라이브가 섹터를 재 할당 할 수 있지만 새로 재 할당 된 섹터에 어떤 데이터를 쓸 것인지 전혀 알지 못한다는 것입니다. 예를 들어 방금 0을 쓴 다음 섹터를 다시 읽은 경우 데이터가 유효하지 않다는 표시없이 모든 0을 반환합니다. 이것은 본질적으로 데이터 손상과 동일합니다. 드라이브는 다양한 이유로 오류를 추적하는 호스트를 계산할 수 없습니다 (예를 들어, 드라이브가 새 호스트로 이동 한 경우 어떻게됩니까?). 데이터를 처리 할 수 ​​없을 때는 아무 것도하지 않는 것이 가장 좋습니다. 복구되지 않습니다.

그러나 최신 드라이브는 재 ​​할당 할 수 없을 때 불량 섹터의 위치를 ​​저장합니다. 재 할당을 기다리는 불량 섹터의 수는 SMART 데이터에서 찾을 수 있습니다. 재 할당 대기중인 불량 섹터 중 하나에 대한 쓰기가 수행 된 경우, 재 할당 후 드라이브에 유효한 데이터를 쓸 수 있기 때문에 재 할당이 수행됩니다. 따라서 사람들이 나쁜 부문에 글을 쓰면 재 할당한다고 말할 때 그것은 실제로 절반에 불과합니다. 드라이브가 자동으로 재 할당 할 수없는 모든 불량 섹터를 발견 할 수 있도록 드라이브를 먼저 읽어야합니다. 따라서 전체 드라이브를 작성할 수 있으며 SMART 데이터는 재 할당 대기중인 불량 섹터가 없다고 말하지만 모든 불량 섹터의 드라이브를 반드시 지운 것은 아닙니다. 따라서 모든 불량 섹터의 드라이브를 정말로 지우려면

재 할당 할 수없는 불량 블록을 처리하는 다른 방법이 있습니다. 드라이브가 중복 RAID 구성 (예 : RAID 0 이외)의 일부인 경우 RAID 소프트웨어는 다른 드라이브에서 불량 섹터에 대한 데이터를 자동으로 복구하여 재 할당 된 섹터에 기록해야합니다. SCSI 디스크에는 블록에 쓸 유효한 데이터가없는 경우에도 호스트가 재 할당을 강제하기 위해 사용할 수있는 명시 적 재 할당 블록 명령이 있지만 사용 수준은 매우 낮습니다.


1
적어도 일부 Seagate HDD가 Write-Read-Verify를 지원한다는 점을 언급 할 가치가 있습니다 hdparm -R(최근 hdparm 을 사용 한다고 가정). 이는 쓰기 성능이 크게 저하됩니다 (모든 쓰기는 이제 후속 읽기를 발생시키기 때문에 쓰기 처리량 및 쓰기 IOPS를 대략 절반으로 줄입니다). 그러나 하드웨어가이를 지원하고 작업량이 읽기 무거운 경우 이는 매우 예방 가능한 조치 일 수 있습니다.
CVn

2

당신이해야 할 일은 다음과 같습니다.

e2fsck -c /dev/hda1

/ dev / hda1이 (언 마운트 된) 파티션이라고 가정합니다. 또는:

e2fsck -c -c /dev/hda1

(느린) 비파괴 읽기 쓰기 테스트를 수행합니다. 여전히 마운트를 해제해야합니다. 그래도 이것이 손실 된 데이터에 대한 세부 정보를 제공하지는 않는다고 생각합니다.


그러나 불량 블록에 대해 SMART의 정보를 사용하지 않는 것은 유감입니다. SMART의 불량 블록 정보를 사용하고 smartmontools.sourceforge.net/badblockhowto.html 또는 serverfault.com/a/106130/68972에 설명 된대로 불량 블록 정보를 사용하고 해당 파일을 피하거나 복구하려는 fsck 도구가없는 이유가 궁금합니다 . ..
imz-Ivan Zakharyaschev

2

Michael은 정확하고 대부분의 경우 저렴한 드라이브를 교체한다고 말합니다. 그러나 백업이없고 드라이브에서 중요한 데이터를 얻지 못하거나 드라이브를 복구하려는 경우 spinrite를 사용 하여 최고 수준 으로 시도 할 수 있습니다.

몇 년 전에 소음이 들리기 시작한 랩톱 드라이브가있었습니다. 불량 블록은 드라이브에 최종 사용자가 볼 수있는 불량 블록이 118 개 정도 인 것으로 나타났습니다. SpinRite를 이미 가지고 있었으므로 새 드라이브를 구입하기 전에 시도해보기로 결정했습니다. 드라이브 불량 블록에서 spinrite를 실행 한 후 불량 블록이 0으로 표시되고 소음이 중지되었습니다. 드라이브는 그 이후로 2 년 넘게 작동했습니다.


넬슨 당신이 듣고 싶지 않은 모든 답변에 투표를 하시겠습니까? 정상 드라이브는 불량 블록을 자동으로 다시 매핑합니다. 이 작업을 수행하기 위해 어떤 조치를 취해야하는 경우 드라이브가 더 이상 건강하지 않으므로 교체해야합니다.
3dinfluence

아니요, 내 질문에 대답하지 않았기 때문에 하나의 응답 만 다운 보트했습니다. 당신은 spinrite를 제안했습니다, 감사합니다! 내 이해는 건강 드라이브가 쓰여질 때까지 불량 섹터를 다시 매핑 하지 않습니다 . 쓰기를 강제하는 가장 간단한 방법을 찾으려고합니다. 매튜의 제안에 따라 fsck가 똑똑 할 수 있는지 확인하십시오.
Nelson

죄송합니다. 2 개의 답변이 빠르게 표결 된 것을 본 후 결론에 도달했습니다. 귀하는 본인이 생각한 다른 답변에 응답합니다.
3dinfluence

2
쓰기가 블록에 실패하면 불량 섹터 재 맵핑이 발생하는 것이 맞습니다. 파일 시스템에 관한 한 손상된 블록이 있으면 문제의 블록이 메타 데이터 블록 인 경우 fsck에서 문제를 정렬 할 수 있습니다. fsck는 메타 데이터의 오류 만 검사하고 수정합니다. 따라서 데이터 자체를 보장하지 않습니다. BTRFS 및 ZFS와 같은 차세대 파일 시스템은 중복성이있는 경우 올바른 데이터 오류를 감지 할 수 있습니다. 또한 Spinrite는이 데이터를 읽을 때이를 강제 한 다음 반전 된 데이터를 쓰고 다시 읽은 다음 스캔의 일부로 모든 블록에서 데이터를 다시 반전시킵니다.
3dinfluence

1

백업이 있고 이것이 실제 오류가 아니라 논리적 오류라는 것을 알고 있다면이 문제를 해결하는 가장 좋은 방법은 디스크를 0으로 만드는 것입니다.

MHDD를 사용하는 것은 상당히 사용하기 쉽고 Bios의 HDD를 IDE 에뮬레이션으로 설정 한 다음 작업이 완료되면 AHCI로 돌아가는 것을 기억하는 한 걱정할 필요가 없습니다.

MHDD로 부팅하면 ERASE 명령에서 드라이브 유형을 선택하고 선택을 확인하십시오.

시간이 걸릴 수있는 커피를 즐기십시오.

드라이브가 제로화되면 Remap을 ON으로 설정 한 상태에서 scan (f4)을 실행하십시오 (기본값은 꺼짐). 드라이브에 여전히 문제가있는 경우 (플래터에 심각한 손상이 있고 드라이브가 아래쪽으로 기울어 져 있음을 의미 함)이 옵션은 손상된 영역을 드라이브의 건강한 부분에 매핑하여 문제를 "고정"합니다.

UNC 오류가 없으면 축하합니다. 앞으로 몇 년 동안 드라이브가 여전히 친구가 될 수 있습니다.


-1

디스크가 손상되면 교체하십시오. 더 떨어져 나갈 위험은 없습니다.


나는 디스크가 나쁘다는 것을 알고 위험을 피하기 위해 백업을하는 것에 대해 명백했다.
Nelson

2
그것은 당신이 도박을 할 의향이 있다는 것을 의미합니다. 나는 그것이 당신이 그 조언을 기꺼이 무시하고 있다는 것을 대체해서는 안된다는 것을 의미한다고 생각하지 않습니다. 디스크가 떨어져서 백업을하면 시스템 자체를 구할 수있을 것 같지 않으며, 성능이 저하되면 문제가 발생하기 쉽습니다.
Michael Graff

3
이 답변은 코멘트가되어야합니다 ... 질문은 구체적이고 흥미 롭습니다. 따라서 이것은 답이 아닙니다.
Pitto
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.