다행스럽게도 일부 디스크 액세스 시간을 측정하는 동안 모두 0으로 쓰여진 SSD의 파일에 0이 아닌 바이트가 하나 포함되어 있음을 발견했습니다.
파일을 보관하고 새 파일로 동일한 실험을 시도했지만 0이 아닌 바이트를 더 이상 찾을 수 없습니다.
그런 다음 모든 파일을 삭제하고 다시 시작했지만 파일 중 하나에서 0이 아닌 바이트만 다시 찾았습니다.
그런 다음 나는 달렸다 smartctl -t long. 전체 "표면"을 테스트한다는 내용을 읽었으므로 SSD의 경우 이는 모든 바이트를 쓰거나 읽고 어딘가에 언급된 오류를 예상하는 것을 의미한다고 가정했지만 아무것도 찾을 수 없습니다.
나는 기록된 모든 바이트가 RAM을 통과하기 때문에 궁극적으로 여전히 RAM 버그일 수 있다고 생각합니다.
비트가 불안정한 RAM이 아닌 디스크에 있는지 확인하고 싶다면 smartctl이를 어떻게든 증명할 수 있습니까?
답변1
내 질문을 삭제할 수 있지만 @likkachu가 댓글에서 제안한 대로 아래에 설명된 방식이 답입니다. 그리고 다른 사람들에게 나처럼 성급하게 결론을 내리지 말고 그것이 디스크일 수 있다고 가정하지 말라고 경고하십시오.
그건칩 램의견에서 제안한 것처럼 SSD에 결함이 있음을 증명하는 것보다 메모리 테스터를 실행하는 것이 더 쉬울 것입니다. 나는 사용했다
- memtester(우분투 및 기타 배포판에서 사용 가능)는 RAM 문제를 신속하게 표시할 수 있습니다. memtester를 사용하여 실제 주소를 찾을 수 없습니다.
- memtest86+는 UEFI 부팅으로 인해 부팅이 어려워서
ddmemtest86 이미지를 USB에 넣어서 실행하곤 했습니다. 그것은 나에게 실제 주소를 제공합니다. 그러나 실제로 가장 간단한 것은 다음과 같습니다. - memtest(또는 memtest=n, 여기서 n은 [1..17]에 있음) 매개변수를 커널 부팅 매개변수로 추가합니다. 예를 들어 단일 부팅에 대해 grub의 부팅 매개변수를 편집합니다(메뉴가 일반적으로 건너뛰었습니다.)
커널이 플레이크 주소를 찾았습니다. /var/log/kern.log다음과 같은 내용을 확인하세요.
bad mem addr 0x00000000a31b7320 - 0x00000000a31b7328 reserved
그런 다음 추가했습니다.
GRUB_BADRAM="0x0a31b7320,0xffffffff0"
그냥 도망 /etc/default/grub쳤어요 update-grub. 마스크에는 9자리 숫자가 있습니다. 8비트 숫자의 경우 이는 각 4GB RAM 블록에 적용됩니다.
시작 후 다음 /var/log/kern.log내용이 포함됩니다.
reserve setup_data: [mem 0x00000000a31b7000-0x00000000a31b7fff] unusable
이는 grub이나 커널이 마스크를 4096바이트의 전체 페이지로 반올림한다는 것을 의미합니다. 이는 마스크에 너무 구체적으로 지정해도 해가 되지 않음을 의미합니다 GRUB_BADRAM. 다시 실행 memtester해 보면 문제가 발견되지 않습니다.