
내 Linux 시스템의 syslog에 SMART 오류가 발생하기 시작했습니다. 나는 그것을 추적했고 문제가 디스크의 단일 블록이라고 생각했습니다. 디스크에서 해당 블록 하나를 쉽게 재할당하려면 어떻게 해야 합니까? 이 과정에서 어떤 파일이 파괴되었는지 알고 싶습니다. (디스크에서 하나의 블록이 실패하면 다른 블록도 뒤따를 가능성이 높다는 것을 알고 있습니다. 저는 좋은 지속적인 백업을 갖고 있으며 이 디스크가 계속 작동하도록 노력하고 싶습니다.)
웹에서 검색하면 다음과 같은 결과가 나옵니다.배드 블록 하우투, 마운트 해제된 디스크의 수동 프로세스를 설명합니다. 복잡하고 오류가 발생하기 쉬운 것 같습니다. 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
전체 smartctl 덤프가 있습니다.페이스트빈에.
답변1
시도해 볼 수도 있습니다 hdparm --write-sector <LBA> /dev/ice
.
다른 방법은 모르겠습니다. LBA를 파일 시스템 블록으로 수동으로 변환해야 합니다(이미 찾았습니다).
답변2
저는 WD용 디스크 펌웨어를 작성하곤 했고, 불량 블록을 재할당하는 펌웨어를 작성한 적도 있습니다.
첫째, 대부분의 불량 블록은 쓰기가 아닌 읽기에서 감지됩니다. 쓰기는 맹목적으로 수행됩니다. 즉, 데이터가 확인되지 않고 기록됩니다. 따라서 쓰기 시 미디어가 불량한 경우 호스트가 해당 섹터를 읽을 때까지 이를 알 수 없습니다. 올바른 섹터를 찾기 위해 쓰기 시 읽는 섹터(섹터 헤더)의 작은 부분이 있으므로 섹터 헤더를 읽는 데 오류가 있는 경우 드라이브는 섹터를 다시 할당하고 수신된 데이터로 기록합니다. 쓰기 명령에서. 그러나 대부분의 불량 블록은 읽기에서 감지되며, 섹터에 대한 쓰기가 성공했다고 해서 미디어가 양호하거나 섹터가 재할당되었음을 의미하는 것은 아닙니다.
이제 불량 블록 재할당(재할당이라고도 함)에 대해 알아보겠습니다. 예, 일반적으로 드라이브는 오류가 충분히 심각한 경우(즉, ECC 오류가 충분히 심각한 경우) 섹터 재할당을 시도하지만 드라이브는 ECC 수정 후에도 여전히 데이터를 복구할 수 있습니다. 일반적으로 이 작업은 자동으로 수행됩니다. 유일한 예외는 호스트가 이전에 드라이브에 자동 재할당을 수행하지 않도록 지시할 수 있었지만 이것이 거의 수행되지 않는다는 것입니다.
그렇다면 드라이브가 읽기를 수행하고 데이터를 복구할 수 없으면 어떻게 될까요? 아무것도 아님. 오류가 호스트에 보고되지만 재할당은 수행되지 않습니다. 문제는 드라이브가 섹터를 재할당할 수 있지만 새로 재할당된 섹터에 어떤 데이터를 쓸지 전혀 모른다는 것입니다. 예를 들어 0을 여러 개 쓴 다음 섹터를 다시 읽으면 데이터가 유효하지 않다는 표시 없이 모든 0을 반환합니다. 이는 본질적으로 데이터 손상과 동일합니다. 드라이브는 다양한 이유로(예: 드라이브를 새 호스트로 이동한 경우 어떻게 될까요?) 오류를 추적하는 호스트에 의존할 수 없으므로 최선의 조치는 데이터가 오류를 추적할 수 없을 때 아무것도 하지 않는 것입니다. 복구할 수 없습니다.
그러나 최신 드라이브는 불량 섹터를 재할당할 수 없는 경우 해당 위치를 저장합니다. 재할당을 기다리는 불량 섹터 수는 SMART 데이터에서 확인할 수 있습니다. 재할당을 기다리는 불량 섹터 중 하나에 쓰기가 수행되면 이제 드라이브에 재할당 후 쓸 수 있는 유효한 데이터가 있으므로 재할당이 수행됩니다. 따라서 사람들이 불량 섹터에 글을 쓰면 이를 재할당할 것이라고 말하는 것은 실제로 이야기의 절반에 불과합니다. 드라이브가 자동으로 재할당될 수 없는 모든 불량 섹터를 검색할 수 있도록 먼저 드라이브를 읽어야 합니다. 따라서 전체 드라이브를 쓸 수 있으며 SMART 데이터에는 재할당을 기다리는 불량 섹터가 없다고 표시되지만 모든 불량 섹터의 드라이브를 반드시 지울 필요는 없습니다. 따라서 드라이브에서 모든 불량 섹터를 지우고 싶다면 가장 좋은 방법은 먼저 전체 드라이브를 읽은 다음 전체 드라이브에 쓰는 것입니다(물론 이렇게 하면 드라이브에 있는 이전 데이터가 모두 삭제됩니다).
재할당할 수 없는 불량 블록을 처리하는 다른 방법이 있습니다. 드라이브가 중복 RAID 구성(즉, RAID 0이 아닌 구성)의 일부인 경우 RAID 소프트웨어는 다른 드라이브에서 불량 섹터에 대한 데이터를 자동으로 복구하여 재할당된 섹터에 기록해야 합니다. SCSI 디스크에는 블록에 쓸 유효한 데이터가 없는 경우에도 강제로 재할당하기 위해 호스트가 사용할 수 있는 명시적인 블록 재할당 명령이 있지만 그 사용 수준은 매우 낮습니다.
답변3
내 생각에 당신이 해야 할 일은 다음과 같습니다.
e2fsck -c /dev/hda1
/dev/hda1이 (마운트 해제된) 파티션이라고 가정합니다. 또는:
e2fsck -c -c /dev/hda1
(느린) 비파괴 읽기-쓰기 테스트를 수행합니다. 여전히 마운트 해제해야 합니다. 하지만 이것이 손실된 데이터에 대한 세부 정보를 제공하지는 않을 것 같습니다.
답변4
백업이 있고 이것이 물리적 오류가 아닌 논리적 오류임을 알고 있는 경우 이를 해결하는 가장 좋은 방법은 디스크를 0으로 만드는 것입니다.
저는 MHDD를 사용하겠습니다. 사용하기 매우 쉽고 Bios에서 HDD를 IDE 에뮬레이션으로 설정한 다음 작업이 완료되면 AHCI로 다시 설정하는 것을 기억하는 한 걱정할 필요가 없습니다.
MHDD로 부팅한 후 ERASE 명령에서 드라이브 유형을 선택하고 선택을 확인합니다.
커피를 마시려면 시간이 좀 걸릴 수 있습니다.
드라이브가 제로화되면 Remap을 ON(기본값은 꺼짐)으로 설정하여 스캔(f4)을 실행합니다. 드라이브에 여전히 문제가 있는 경우(플래터에 물리적 손상이 있고 드라이브가 지속적으로 하향 경사를 이루고 있음을 의미) 이 옵션은 손상된 영역을 드라이브의 정상 부분에 매핑하여 문제를 "수정"합니다.
UNC 오류가 없다면 귀하와 귀하의 드라이브가 앞으로도 몇 년 동안 친구가 될 수 있다는 것을 축하합니다.