이 badblocks유틸리티를 사용하면 사용자는 장치에서 배드 블록을 찾을 수 있으며 e2fsck -c이러한 배드 블록을 배드 블록 inode에 추가하여 실제 데이터에 사용되지 않도록 할 수 있습니다. 그러나 SSD의 경우 불량 섹터는 종종 드라이브에 의해 투명하게 재할당(재매핑)되는 것으로 알려져 있습니다(그러나 쓰기가 발생할 때만 해당). 그렇다면 /를 SSD에서 사용하는 것이 합리적입니까 badblocks?e2fsck -c
제 생각에는
badblockssmartctl예를 들어 총 불량 블록 수를 고려하여 SSD 상태에 대한 정보를 별도로 얻는 것이 합리적입니다. ( smartmontools가 동일한 작업을 수행할 수 있는지는 모르겠습니다 ... 아마도 오랜 기간 동안 테스트한 후에일 것입니다. 시간이 지났지smartctl -t long만 명시적인 문서를 살펴보지 않았습니다);e2fsck -c관련 번호(논리 주소?)가 재할당으로 인해 더 이상 사용되지 않을 수 있으므로 사용하면 안 됩니다 (불량 블록 inode에 불량 블록을 추가함).
그러나 이러한 유틸리티의 매뉴얼 페이지에는 SSD 상태에 대한 경고가 포함되어 있지 않습니다. 그래서 알고 싶어요...
답변1
하드 드라이브는 쓰기 시 실패한 섹터를 다시 매핑했으며 이는 수십 년 동안 SSD에만 국한된 일이 아닙니다. 하드 드라이브에 비해 SSD의 주요 문제는 badblocks전체 드라이브에 쓸 때 발생하는 마모 정도입니다(그러나 이마저도 반드시 심각한 것은 아닙니다).
외부에서 볼 수 있는 블록 식별자에 영향을 주지 않는 이 재매핑은 다음을 사용하여 badblocks방지할 수 있습니다.글쓰기블록에 쓰는 것은 아무 소용이 없습니다. 잘못된 블록을 발견하면 드라이브가 필요한 경우 다시 매핑할 수 있도록 블록에 쓰는 것이 실제로 더 좋습니다. 읽을 수 없는 블록을 식별하는 데는 특히 유용하지 않습니다 badblocks. 데이터가 중요한 경우 ddrescue복구 시도와 같은 도구를 사용하는 것이 더 좋으며, 데이터가 아닌 경우 필요한 경우 드라이브를 다시 매핑할 수 있도록 블록을 덮어쓰는 것이 좋습니다.
드라이브 자체 테스트를 사용하여 불량 블록을 식별할 수 있습니다. 가장 좋은 방법은 오프라인 테스트입니다. 오프라인 테스트는 가장 많은 오류 추적 필드를 업데이트하여 가장 많은 오류를 확인하는 방법입니다. 이 명령을 정기적으로 실행하고 0이 아닌 "오프라인 수정 불가능" 섹터 수를 찾는 경우 를 실행하는 것과 동일한 결과를 얻어야 합니다 badblocks. (실행하여 smartctl -a"업데이트됨" 열에 "오프라인"이 있는 필드를 확인하세요.)
어쨌든 최신 드라이브에서는 다시 매핑할 수 없을 정도로 드라이브 상태가 나빠져서 파일 시스템에서 블록을 제외하는 것이 유용할 경우 이제 재활용해야 할 때입니다.
당신은 또한 볼 수 있습니다아치 위키토론 badblocksv. 재매핑. badblocks드라이브 펌웨어가 불량 블록을 인식하도록 강제하는 데 사용할 수 있지만 SSD에 대한 보다 타겟화된 접근 방식(적어도 쓰기 시)이 더 나을 것이라고 생각합니다.