9 개월 동안 SSD에 50GB 이상의 쓰기 / 1 일 평균 Windows 10

업데이트 : 드라이브에서 다음 폴더를 이동 한 다음 심볼릭 링크를 사용하면 C :에 지속적인 쓰기가 제거되었습니다.

• %LocalAppData%\Google\Chrome - 쉽게 가장 큰 소비자.
• %LocalAppData%\Microsoft\Windows\FileHistory

나는 그들을 갓 포맷 된 드라이브로 옮겼다. 3 시간 후 이미 10.5GB의 읽기와 10.3GB의 쓰기가있었습니다. 그와 동시에 Drive C : \는 3.5GB의 읽기와 1.3GB의 쓰기 만 보았습니다.

이것은 잠시 나를 괴롭혔다. Windows 10 Education은 PC가 한 번에 며칠 동안 사용되지 않더라도 명백한 이유없이 C : \ 드라이브에 데이터를 지속적으로 기록하는 것으로 보입니다. 내가 쓰는 소스 나 그것이 쓰는 데이터를 찾을 수 없다.

단 9 개월 만에 500GB 삼성 850Evo의 드라이브 수명 중 10 %가 소비되었습니다. Windows는 백그라운드에서 많은 로깅 및 추적을 수행하고 있기 때문에 이럴 수 있습니까? 그게 이유라면, 나는 그것을 무능력하게하는 방법에 대한 조언을 원합니다. 내가 떠날 수있는 것이 아무것도 없다고 생각합니다. C:\ 드라이브 (고장에 대한 자세한 내용)

HWInfo64는 드라이브 통계를 추적하기 위해 지난 12.75 일 (가동 시간 14 일) 실행되었습니다. 이 기간 동안 PC는 7 월 1 일부터 7 월 5 일 또는 7 월 8 일 사이에 접촉되지 않았습니다. 평일에는 적어도 18 시간 동안 그대로 있기 때문에 사용 가능한 최대 시간은 약 5 일입니다.

다음은 대부분의 드라이브에 대한 분석입니다.

• 500GB Samsung 850 Evo ( Age: 0.7yr | HostWrites: 13.3TB(~50GB/day) )

  • C:\ 지난 2 주 동안 : 새로운 것은 설치되지 않았지만 900GB (64GB / 일) 작성되었습니다. 사용 일 5 일 동안 180GB / 일입니다. ShadowCopy (시스템 복원)가 10 %로 설정되고이 드라이브에 대한 FileHistory가 없습니다.

• 500GB Samsung 850 Evo ( Age: 1.7yr | HostWrites: 8.6TB )

  • A:\ 중요 데이터 및 UserProfile 폴더가 여기에 매핑됩니다. 이것은 FileHistory가 활성화 된 유일한 드라이브입니다. ShadowCopy (시스템 복원)가 15 %로 설정됩니다.
    한 번 Windows 7 C : 드라이브는 약 1 년 동안이었습니다.

• 250GB Samsung 840 Evo ( Age: 3.7yr | HostWrites: 10.5TB ) & amp; 256GB 중요한 m4 ( Age: 4.8yr | HostWrites: 25TB )

  • D:\ 스트라이프 된 StorageSpace (raid0)를 생성하기 위해 드라이브를 풀링합니다. PageFile, TEMP 폴더, SoftwareDistribution, NodeJS / npm, Origin, Steam 및 녹화 된 TV가 여기에 저장됩니다. 이 드라이브에는 ShadowCopy (시스템 복원) 또는 FileHistory가 없습니다.
  • Windows 7에서 각 드라이브는 한 번에 시스템 드라이브였으며 1 년 동안 840Evo, 3 년 동안 m4였습니다. 지난 30 일 동안 m4가 막 시작하지 못했고 무거운 글쓰기 중일 때 종종 오프라인 상태가됩니다. HWInfo 통계는 심지어 체중을 당기지 않는 것을 보여줍니다. StorageSpaces는 아직 드라이브를 제거하지 못했던 드라이브를 잘 관리합니다. 이것은 5 년 만에 25TB의 HostWrites 이후입니다. 850Evo는 이미 그 반쪽에 있습니다. 이것은이 질문 뒤에있는 동기 부여 요소입니다.

• 4TB HGST 데스크 스타 ( Age: 2.6yr | HostWrites: 17TB ) & amp; 4TB HGST 데스크 스타 ( Age: 0.75yr | HostWrites: 7TB )

  • B:\ & amp; M:\ 드라이브는 풀링되어 2TB Stripped 및 3TB Mirrored StorageSpace를 각각 생성합니다. 어느 볼륨에도 FileHistory 또는 ShadowCopy 보호 기능이 없습니다. 영화, 음악 등은에 저장됩니다. B:\ 엔. M:\ 변경된 파일이 버전 관리되고 10 분마다 백업되는 모든 FileHistory의 백업 저장소입니다.

보시다시피, Windows 7은 많은 양의 데이터 근처에 마모가 없습니다. 다음은 HWInfo64의 스크린 샷입니다.

작업 관리자를 사용하여 어떤 프로세스가 디스크에 가장 많은 데이터를 쓰는지 볼 수 있습니다.

열다 작업 관리자 , 세부 탭을 클릭하고 표 머리글을 마우스 오른쪽 버튼으로 클릭 한 다음 열 선택 . 그런 다음 I / O 읽기 바이트 , I / O 쓰기 바이트 , 및 I / O 다른 바이트 클릭 승인 .

즉, 파일 기록은 여기에 있다고 생각합니다.

내 경험에 의하면, File History 데이터베이스 ( Catalog1.edb 과 Catalog2.edb )는 시간이 지남에 따라 매우 커질 수 있습니다. 설상가상으로, 기록이 업데이트 될 때마다 (시스템에 구성된대로 매 10 분마다) 전체 내용이 다시 쓰여지고 NTFS 압축을 사용하면 Windows에서 압축을 해제합니다. 이로 인해 시간이 지남에 따라 디스크에 많은 양의 쓰기가 발생할 수 있습니다.

어떤 드라이브가 파일 기록에 포함되는지에 관계없이이 데이터베이스는 다음 위치의 사용자 프로필에 저장됩니다. C:\Users\<username>\AppData\Local\Microsoft\Windows\FileHistory\Configuration. 한 쌍의 100MB 데이터베이스를 사용하면 매번 두 파일을 모두 기록한다고 가정 할 때 업데이트 당 10 분에 하루에 거의 30GB가 시스템 볼륨에 기록됩니다.

내 솔루션은 연결 지점을 사용하는 것이 었습니다. 파일 기록 서비스를 중지하고 쓰기 내구성이 문제가되지 않는 다른 위치로 Configuration 폴더를 이동 한 다음 폴더의 원래 위치 대신 새 위치를 가리키는 연결 지점을 만들고 파일 기록 서비스를 다시 시작합니다. 그게 문제를 해결해야합니다.

Windows에는 업데이트 공유 시스템이 내장되어 있으므로이 기능을 해제해야합니다.

설정 & gt; 업데이트 & amp; 보안 & gt; Windows Update & gt; 고급 옵션 & gt; 방법 선택   업데이트가 파생됩니다.

또한 Windows 백업 시스템을 켜지 않았는지 확인하십시오.

설정 & gt; 업데이트 & amp; 보안 & gt; 지원.