badblocks 불량 디스크 컨트롤러를 검색할 수 없습니다.

badblocks 불량 디스크 컨트롤러를 검색할 수 없습니다.

내 HDD에 파일 손상 문제가 있습니다(동일 컴퓨터의 SDD는 정상적으로 작동함).

for i in {1..10}; do
  dd if=/dev/zero of=zeroes_$i.dat bs=512 count=4M
done
md5sum zeroes_*

일부 파일에 대해 올바른 체크섬 a981130cf2b7e09f4686dc273cf7187e를 생성하지만 일반적으로 다른 파일을 생성합니다. grep일부 파일에서 0이 아닌 문자가 발견된 것을 확인했습니다. 따라서 여기에는 확실히 뭔가 수상한 점이 있습니다(하드웨어를 다른 컴퓨터와 교체한 결과 디스크보다는 컨트롤러에 더 가깝다고 생각되지만 이것이 이 질문의 주제는 아닙니다). 체크섬이 실패하는 0_$i.dat 파일이 항상 여러 개 있기 때문에 이는 "재현 가능"합니다.

이제 이상한 점은 badblocks -wvs -b 32768 -c 20484가지 모드를 테스트한 후에도 오류가 보고되지 않는다는 것입니다. 손상된 IO에서 불량 블록이 발견되지 않는 원인은 무엇입니까? 나를 혼란스럽게 하는 것은 md5sum읽은 내용 dd과 쓴 내용이 다르지만 badblocks다시 읽는 내용은 쓴 내용과 똑같다는 것입니다. 그거 어디서 나온 거야?

편집: 아이디어를 주신 Dominic에게 감사드립니다. IIUC, 컨트롤러에 잘못된 캐시가 있어 잘못된 체크섬이 발생할 수 있으며, 잘못된 블록에는 캐시를 비활성화하고(예: 디스크를 다시 읽기 전에 전체 디스크에 쓰기) 실제로 컨트롤러 대신 디스크를 테스트하는 메커니즘이 있습니다. 그렇죠?

답변1

편집에서 언급한 캐시는 OS 관리 캐시, 즉 RAM에 상주하는 캐시일 수도 있습니다. 다음 조건으로 인해 이러한 증상이 설명될 수도 있습니다.

  • 원격 주소가 있는 RAM의 일부 부분에 결함이 있습니다. 운영 체제는 RAM 시작 부분에 로드되므로 영향을 받지 않습니다.
  • 나중에 디스크에 많은 양의 데이터를 읽거나 쓸 때 문제가 있는 부분을 포함하여 RAM을 모두 사용하게 됩니다.
  • badblocks는 소량의 RAM(고장 가능성 없음)만 사용하고 디스크 IO에 대해 OS 캐시를 비활성화하므로 영향을 받지 않습니다.
  • 반면, md5sum이 디스크를 "읽는" 경우 실제로는 운영 체제에 의해 캐시된 데이터를 읽는 것이므로 오류가 발생하는 경우가 있습니다.

따라서 나와 같은 증상을 가진 다른 독자들을 위해 다음을 실행하십시오 memtest.

관련 정보