하드 디스크의 데이터가 Windows에 액세스하지 않고 데이터에 액세스하려고 할 때 발생했다는 경고없이 성능이 저하 될 수 있습니까?

하드 디스크의 물리적 성능 저하로 인해 OS 'noticing'없이 파일 내용에서 비트가 'flip'되어 파일을 읽을 때 알려줄 가능성이 있습니까? 예를 들어 ASCII 텍스트 파일 (이진 0111000 0 )의 'p'가 'q'(0111000 1 )로 변경되면 사용자 (me)는 파일을 열 수 있으며 실패를 인식하지 못하고 'q'를 볼 수 있습니다 발생 했습니까?

FAT, NTFS 또는 ReFS와 관련된 답변에 관심이 있습니다.

OS 가이로부터 나를 보호하는지, 또는 복사 / 시간의 차이가 없는지 데이터를 확인 해야하는지 알고 싶습니다.

예 , 비트 부패라는 것이 있습니다.

그러나 아닙니다 . 눈에 띄지 않습니다.

드라이브가 플래터에 섹터를 쓰면 RAM에 저장된 것과 같은 방식으로 비트를 쓰지 않고 인코딩을 사용하여 동일한 비트의 시퀀스가 ​​너무 길지 않도록합니다. ECC 코드를 추가하여 몇 비트에 영향을 미치는 오류를 복구하고 몇 비트 이상에 영향을 미치는 오류를 감지 할 수 있습니다.

드라이브는 섹터를 읽을 때 이러한 ECC 코드를 확인하고 필요한 경우 데이터를 복구합니다. 다음에 일어날 일은 드라이브의 환경과 펌웨어에 따라 다르며, 이는 드라이브 지정에 영향을받습니다.

• 섹터를 읽을 수 있고 ECC 문제가없는 경우 OS로 전달됩니다.
• 섹터를 쉽게 복구 할 수있는 경우 복구 된 버전을 디스크에 쓰고 다시 읽고 확인하여 오류가 임의 오류인지 (cosmic rays ...) 또는 매체에 체계적인 오류가 있는지 확인할 수 있습니다.
• 드라이브가 미디어에 오류가 있다고 판단하면 섹터를 재 할당합니다
• RAID 드라이브로 지정된 드라이브에서 몇 번의 읽기 시도 후에 섹터를 읽거나 수정할 수없는 경우 드라이브는 포기하고 섹터를 재 할당하며 컨트롤러에 문제가 있음을 알려줍니다. RAID 컨트롤러를 사용하여 다른 RAID 멤버에서 섹터를 재구성하고 실패한 드라이브에 다시 기록한 다음 문제가없는 재 할당 된 섹터에 저장합니다.
• 데스크탑 드라이브 에서 섹터를 읽거나 수정할 수없는 경우 드라이브는 더 많은 부분을 읽으려고 시도합니다. 드라이브의 품질에 따라 헤드 위치 변경, 반복적으로 읽을 때 뒤집힌 비트가 있는지 확인, 가장 약한 비트 확인 및 기타 몇 가지가 포함될 수 있습니다. 이러한 시도 중 하나라도 성공하면 드라이브는 섹터를 재 할당하고 복구 된 데이터를 다시 씁니다.

(이것은 "데스크톱", "NAS / RAID"또는 "비디오 감시"드라이브로 판매되는 드라이브의 주요 차이점 중 하나입니다. RAID 드라이브는 단시간 내에 포기하지 않고 컨트롤러가 섹터를 복구하도록합니다. 사용자가 몇 초 동안 기다리면 데이터 손실을 알리는 것보다 데스크탑 드라이브가 계속해서 다시 시도하며, 비디오 드라이브는 일반적으로 손상된 프레임이 승리하므로 오류 복구보다 일정한 데이터 속도를 유지합니다. 눈치 채지 마.)

어쨌든, 드라이브는 비트 썩음이 있는지 알 수 있고, 일반적으로 복구 할 수 있으며, 그렇지 않으면 컨트롤러에게 드라이버에게 OS를 알려줄 것입니다. 그런 다음,이 오류를 사용자에게 제시하고 조치를 취하는 것은 OS에 달려 있습니다. 이것이 사이 버나드가 말하는 이유입니다

나는 단일 비트 오류를 ​​직접 목격 한 적이 없지만 전체 섹터가 고장난 하드 드라이브를 많이 보았습니다.

드라이브는 섹터에 문제가 있음을 알고 있지만 어떤 비트가 실패했는지는 모릅니다. (실패한 하나의 단일 비트는 항상 ECC에 의해 포착됩니다).

chkdsk 및 파일 시스템 자동 복구는 파일 내에서 데이터를 reparing하지 않습니다 . 그것들은 파일 시스템의 구조를 손상시키는 것을 목표로합니다. 디렉토리 항목과 할당 된 블록 수 사이의 파일 크기가 다른 것처럼. NTFS의 자체 복구 기능은 구조적 손상을 감지하여 데이터에 더 이상 영향을 미치지 않도록하며 이미 손상된 데이터는 복구하지 않습니다.

물론 데이터가 손상 될 수있는 다른 이유가 있습니다. 예를 들어. 컨트롤러의 불량 RAM은 드라이브로 전송되기 전에 데이터를 변경할 수 있습니다. 이 경우 드라이브의 어떤 메커니즘도 데이터를 감지하거나 복구하지 않으므로 파일 시스템의 구조가 손상 될 수 있습니다. 다른 이유로는 일반 소프트웨어 버그, 디스크 쓰기 중 정전 (파일 시스템 저널링으로 해결되지만) 또는 잘못된 파일 시스템 드라이버 (Linux의 NTFS 드라이버는 오랫동안 리버스 엔지니어링되어 문서화되지 않았기 때문에 오랫동안 읽기 전용으로 기본 설정 됨)가 있습니다. 개발자는 자신의 코드를 신뢰하지 않았습니다).

응용 프로그램이 모든 상황에서 데이터가있는 경우 작업 복사본을 유지하기 위해 응용 프로그램이 다른 데이터 센터의 두 개의 다른 서버에 모든 파일을 저장하는이 시나리오를 한 번 수행했습니다. 몇 달 후 사본 중 하나에서 모든 파일의 약 0.1 %가 응용 프로그램이 데이터베이스에 저장 한 MD5 합계와 일치하지 않는 것으로 나타났습니다. 서버와 SAN 사이의 광섬유 케이블에 결함이있는 것으로 나타났습니다.

이러한 다른 이유 때문에 ZFS와 같은 일부 파일 시스템은 오류를 감지하기 위해 추가 체크섬 정보를 유지합니다. 비트 썩음보다 잘못 될 수있는 더 많은 것들로부터 당신을 보호하도록 설계되었습니다.

예, 하드 드라이브는 OS의 경고없이 성능을 저하시킬 수 있습니다. 비트 로트 라고 합니다. 나는 단일 비트 오류를 ​​직접 목격 한 적이 없지만 전체 섹터가 고장난 하드 드라이브를 많이 보았습니다.

Windows는 NTFS 파일 시스템의 구조를 넘어 파일 내용을 기본적으로 보호하지 않습니다. NTFS를 책으로 생각하십시오. 글쎄, 목차 만 보호하고 일이 일치하는지 확인합니다. 그러나 페이지 중간에 손상이 있으면 보호 기능이 없습니다. FAT에는 아무것도 없습니다. 하드 드라이브는 섹터별로 ECC 오류 수정을 사용하지만 드라이브는 Windows에 알리지 않습니다. 일부 파일 형식에는 특히 손상을 감지하기 위해 CRC, MD5 또는 SHA 해시가 있지만 아무 것도 수정 하지 않습니다 .

그런 경우에도 해시는 문제가 있음을 알려 주지만 오류의 위치는 알 수 없습니다.

하드 드라이브에는 SMART가있어 하드 드라이브의 상태를 모니터링하지만 드라이브가 문을 닫지 않는 한 BIOS는 경고하지 않습니다. 최악의 경우, SMART는 종종 BIOS에서 기본적으로 비활성화되어 있습니다. 소프트웨어를 통해 번호를 모니터링 할 수 있지만 드라이브마다 문제가 다릅니다. 재배치 된 섹터가 많거나 ECC 오류가 계속 발생하는 경우 매일 10 만 개의 새로운 ECC를 보유하고 있다면 이는 나쁜 신호입니다.

많은 파일 형식은 비트 썩음 방지 기능이 없습니다 . TXT 및 BMP와 같이 전혀 보호 기능이 없습니다. Winrar에는 파일을 더 크게 만드는 아카이브에 패리티 데이터를 추가하는 옵션이 있지만, 추가 된 패리티 데이터의 양에 비례하여 감지하고 이러한 종류의 오류를 복구 할 수 있습니다.

내가 아는 다른 모든 압축 프로그램은 오류를 감지하지만 그것에 대해 아무것도 할 수 없습니다.

결국, 섹터의 오류는 ECC가이를 정정 할 수 없을 정도로 나빠질 것이며 드라이브는 그것이 잘못되어도 읽은 것을 줄 것입니다.

QuickPar 또는 이와 유사한 기능을 사용하여 패리티 데이터 파일을 작성할 수 있지만, 아는 한 자동화 할 방법이 없습니다. 예를 들어 패리티를 수동으로 업데이트해야 할 때 실제로 파일을 직접 변경해야합니다. 파일 그룹에 대한 패리티 데이터를 가질 수도 있지만 1 개의 파일을 변경하면 전체 패리티 세트를 다시 작성해야합니다. 이것은 모두에게 아주 어려운 문제이지만 적은 수의 파일입니다.

네 가능합니다. Windows는 소프트웨어 일뿐입니다. 소프트웨어는 컴퓨터가 따라야 할 일련의 지침입니다.

다른 유형의 일련의 지침 인 책을 생각해보십시오. 책장에 앉아 책을 쓰고 그 책을 읽고 귀찮게하는 사람이 아무도 없다면 그 지침은 무엇을 성취 할 수 있습니까?

이러한 서면 지침에 따라 사람이 지침을 읽고 지침을 따르도록 요구하는 것처럼, 컴퓨터 소프트웨어는 유용한 기능을 수행하기 위해 하드웨어를 요구합니다. 책에 엄청나게 정확하게 쓰여진 지시 사항이 있더라도, 지시 사항을 읽고 결정을 잘못 이행하여도 문제를 예방할 수는 없습니다. 마찬가지로 소프트웨어는 하드웨어가 나쁜 일을하는 것을 막을 수 없습니다. 따라서 손상된 하드웨어는 Microsoft Windows를 포함하여 모든 소프트웨어에서 수행 할 수있는 작업을 물리적으로 극복 할 수 있습니다.

이제 ReFS는 소프트웨어가 데이터에 대한 세부 정보를 저장하고 나중에 소프트웨어가 해당 세부 정보를 비교할 수 있도록 설계되었습니다. 간단한 개념은 "체크섬"인데, 여기서 소프트웨어는 특정 값을 추가하고 해당 값이 예상 결과와 일치하는지 확인합니다. 하드웨어가 해당 소프트웨어를 구현할 때 특정 나쁜 결과가 감지 될 수 있습니다. 이것은 작동 가능성이 매우 높습니다. 그러나 이론적으로 존재할 수있는 잠재적 인 문제의 수는 기본적으로 무한한 수이므로 소프트웨어가 모든 단일 문제를 반드시 감지 할 것이라는 보장은 없습니다. (소프트웨어는 미리 작성된 일련의 지침임을 명심하십시오.)

FAT는 특히 기능이 낮습니다. FAT12는 플로피 디스크 용으로 설계되었으며 최대 4GB의 시스템 용 FAT16 (FAT16의 대부분의 구현은 2GB 이상에서는 작동하지 않았 음). VFAT 확장자가 없으면 11 자보다 긴 파일 이름을 지원하지 않습니다 (일부는 "확장자"라고 함). FAT는 단순히 데이터를 저장하는 능력이 성인에게 가르쳐야 할 참신한 개념이었던 시대에 데이터를 저장하도록 설계되었습니다. FAT가 "최첨단"기술로 여겨졌을 때, 컴퓨터 기술은 아직 널리 보급되지 않았으며 사람들이 고급 기능에 대해 걱정할 정도로 정교하지 않았습니다.

NTFS는 더 많은 기능에 대한 지원을 추가했으며, 아마도 운영 체제에서 사용자 권한을 쉽게 추적 할 수있게했을 것입니다. 다양한 버전의 NTFS가 있습니다. 예를 들어, Moab은 Windows Server 2008이 자동 복구 NTFS에 대한 지원을 추가했다고 지적합니다.어떤 것을 감지 할 수 있습니다. 그러나이 기능은 Windows Server 2008의 새로운 기능이므로 Windows XP (또는 Windows Server 2003 또는 이전 버전)에서는 전혀 지원되지 않습니다. 그럼에도 불구하고 기능 목록을 살펴보면 운영 체제가 디스크를 마운트 할 수 없을 정도로 심각한 문제 또는 운영 체제 커널에 영향을 미치는 디스크의 다른 주요 영역을 통지하는 데 도움이되는 일부 메타 데이터가 포함 된 것으로 보입니다. 모든 단일 파일에서 모든 단일 데이터 조각이이 특정 기능의 영향을받는 것처럼 보이지는 않았습니다.

이러한 운영 체제 용 소프트웨어는 운영 체제가 작업을 수행하는 데 현저한 문제를 일으키지 않는 한 그러한 사실을 알아 차리지 못할 것입니다. 디스크를 검사하는 운영 체제 부분 (운영 체제에 따라 CheckDsk / ChkDsk / ScanDisk / ScanDskW)과 같은 일부 예외가있을 수 있지만 파일 시스템이 감지하지 못하기 때문에 감지 할 수있는 대상에 다소 제한적일 수 있습니다. 디스크 검사에 유용한 대량의 데이터를 저장하지 마십시오.

(RAID5는 이러한 비트를 감지하는 경향이있을 수 있습니다. 모든 비트에는 비정상적인 것을 알아내는 데 도움이되는 패리티 비트가 있습니다. 그럼에도 불구하고 RAID 구현에 따라 문제를 확인하는 검사를 실행해야합니다. 적극적으로 작업하지 않는 디스크의 일부인 경우, 누군가 해당 데이터를 사용하려고 시도 할 때까지 문제가 눈에 띄지 않을 수 있습니다.)

최근에는 비트 수가 많을수록 "1000 만 분의 1"확률과 같은 작은 가능성이 사물에 영향을 줄 가능성이 더 컸습니다. 일반 대중은 또한 사물에 약간의 영향을 줄 수있는 "우주선"에 대해 배웠습니다. 최신 장치에서는 비트가 너무 꽉 채워지기 때문에 비트를 나타내는 물리적 요구 사항이 더 작으므로 작은 영향조차도 비트가 인식되는 방식에 혼란을 줄 수 있습니다. ReFS에는 감지를 돕기 위해 설계된 일부 기능이 있습니다. ReFS에 관한 Wikipedia의 기사에서는 이를 "자동 무결성 검사"라고합니다. 이것이이 파일 시스템의 주목할만한 기능으로 설명 되었 듯이, 그러한 기능은 NTFS보다 더 개발되었을 가능성이 높습니다.