C 드라이브 조각 모음을 수행하면 여유 디스크 공간이 10GB 증가한 이유는 무엇입니까?

Defraggler 를 사용 하여 100GB C : \ 드라이브의 여유 공간을 85GB 로 조각 모음했습니다. 조각 모음을 마친 후 드라이브의 용량이 75GB에 불과했습니다. 10GB의 여유 공간이 어떻게 마술처럼 나타 났습니까? 데이터가 손실 되었습니까?

조각 모음을 수행하기 전에 디스크 정리를 수행했으며 휴지통은 약 11MB에 불과하므로 임시 파일을 정리했기 때문일 수 없습니다. "빈 공간"의 조각 모음을 수행했습니다. 즉, 빈 블록을 연속적으로 재 배열해야합니다.

ntfs disk-space defragment

— Goweon
소스

섀도 복사본과의 상호 작용 일 수 있습니다 (예 : piriform.com/docs/defraggler/technical-information/… )

— horatio

또한 조각 모음에는 조각 모음을하기 전에 휴지통을 비울 수있는 옵션이 있습니다.

— oKtosiTe

답변:

아마도 조각 모음 작업으로 인해 Windows에서 일부 시스템 복원 스냅 샷을 삭제해야 할 수 있습니다. 메타 데이터 오버 헤드가 Windows가 일반적으로 사용하는 것보다 드라이브 공간의 10 %를 차지하게하는 것은 병리학적인 조각화 사례입니다. 그럼에도 불구하고, 나는 그것이 가능한지 확신하지 못한다.

Defraggler의 버전 기록 또는 설명서에 섀도 복사본 제거를 방지하기 위해 파일 조각 모음을 올바르게 수행 할 수 있음을 나타내는 내용이 없습니다. 사실, Defraggler의 지원 포럼에있는 이 스레드 는 그들이 스레드가 진행 중이라는 것을 알고 있지만 (스레드에서 "Official Piriform Bug Fixer"라는 레이블이 붙은 게시판 관리자의 게시물이 있음) 알지만이를 고칠 것인지 여부는 나타내지 않습니다.

볼륨 조각 모음을 수행하면 섀도 복사본이 손실 될 수 있습니다 . 기본적으로 VSS는 기본적으로 16KB 클러스터로 작동하지만 대부분의 NTFS 볼륨은 4KB 클러스터로 포맷되기 때문입니다. 따라서 조각 모음 작업이 16KB 클러스터의 배수가 아닌 데이터를 이동하는 경우 (또는 "이동 된 거리"는 16KB의 배수가 아닌 경우) VSS는이를 변경으로 추적하여 모든 데이터를 제거 할 수 있습니다. 스냅 샷.

MSDN : 파일 조각 모음 :

가능하면 16KB 단위로 서로에 대해 정렬 된 블록으로 데이터를 이동하십시오. 다음과 같은 경우 섀도 복사본 공간이 증가하고 성능이 저하되므로 섀도 복사본을 사용하면 쓰기 중 복사 오버 헤드가 줄어 듭니다.

이동 요청 블록 크기는 16KB보다 작거나 같습니다.

이동 델타는 16KB 씩 증가하지 않습니다.

Vista에 내장 된 조각 모음은이 작업을 수행하지 않습니다 .

사용자에게 분명하지 않은 변경 사항 중 하나는 조각 모음 중 섀도 복사본 최적화입니다. 조각 모음에는 기록 중 복사 작업 및 섀도 복사본 저장 영역 소비를 최소화하는 방식으로 파일 블록을 이동하는 특별한 추론이 있습니다. 이 최적화가 없으면 조각 모음 프로세스에서 오래된 섀도 복사본을 빠르게 삭제할 수 있습니다.

— afrazier
소스

이 답변의 스냅 샷 부분에 대해서는 모르겠지만 조각 모음이 공간을 확보했다고 확신하지 못합니다. 조각 모음이 휴지통을 비 웠을 수 있습니까? 작은 파일을 단일 클러스터로 결합하지 않는 파일 시스템에서 조각 모음을 수행하면 이러한 공간 확보가 어떻게 이루어지는 지 알 수 없습니다. Windows가 계산하지 않은 작은 블록에 10G의 공간이 있다고 상상할 수 있지만 이전에는 그 동작에 대해 들어 보지 못했습니다.

— Slartibartfast 2

@Slartibartfast : 앱이 올바르게 작성되지 않으면 문제가됩니다. 전화를받지 않았으므로 더 많은 증거로 답변을 업데이트하겠습니다. :-)

— afrazier

@afrazier-ThouArtNotDoc의 업데이트 된 답변이 더 나은 일반적인 답변이라고 생각합니다. 섀도 복사본이 OP의 상황에서 중요한 역할을한다는 데 동의해야합니다. "섀도 복사본이 활성화 된 볼륨을 조각 모음하려는 경우 16KB 이상의 클러스터 (또는 할당 단위) 크기를 사용하는 것이 좋습니다. 그렇지 않은 경우 변경 횟수가 발생했습니다. 조각 모음 프로세스로 인해 섀도 복사본이 예상보다 빠르게 삭제 될 수 있습니다. " -MS : "섀도 복사본 전략 설계" technet.microsoft.com/en-us/library/cc728305(WS.10).aspx

— Ƭᴇcʜιᴇ007

@afrazier : 확인했습니다. 이전의 모든 시스템 복원 지점이 사라졌습니다. 구성에서 섀도 복사본에 허용되는 최대 공간으로 12 %를 설정 했으므로 10GB는 무리가 없습니다. 반면에, 9GB 게임을 설치했는데, 이는 단순히 이전 복원 지점을 덮어 쓸 수있었습니다.

— goweon

@firebat : 시스템 복원에 사용되는 공간은 새 파일이 아닌 기존 (스냅 샷 된) 파일의 변경 사항을 추적하기위한 공간입니다. 새로운 게임을 설치해도 시스템 복원 공간에는 영향을 미치지 않지만 큰 패치는 영향을 줄 수 있습니다.

— afrazier

각 조각은 어딘가에서 추적해야합니다. 저장 공간이 필요합니다 (파일 시스템의 배관 내에서 직접 액세스하려는 것이 아닌).

예 : 조각이 1000 개인 단일 파일이 있다고 가정하십시오. 따라서 파일 은 무작위 블록 모음을 통해 저장됩니다. 단일 연속 블록이 아니라. 이는 조각난 파일이 각 조각의 주소를 저장하는 경우에만 파일 시스템의 배관 내에 1000 배 더 많은 저장 공간이 필요하다는 것을 의미합니다. 파일 시스템 배관은 파일의 각 조각 위치에 작은 사전 / 데이터베이스 / 맵 / 테이블 / 목록을 유지합니다. 따라서 파일 시스템 배관의 경우 단일 조각 포인터 목록을 저장하는 데 1000 조각 포인터 목록에 비해 많은 공간이 필요하지 않습니다.

하지만 어쩌면 내가 틀렸을 수도있다.

편집 : 여기에서 지원 정보 :

비주거 데이터 스트림이 너무 세분화되어 유효 할당 맵이 MFT 레코드에 완전히 맞지 않을 경우, 할당 맵은 간접 할당을 포함하는 작은 상주 스트림과 함께 비주류 스트림으로도 저장 될 수 있습니다. 비 상주 데이터 스트림의 유효 비 상주 할당 맵에 매핑된다.

번역 : 조각화가 심한 경우 파일 시스템 배관에 대한 일반적인 경우는 적용되지 않습니다. 따라서 FS는 단편화를 관리하고 단편화를 관리하기 위해 추가 저장 공간 비용이 들도록 조치를 취해야합니다. 처음부터 정확히 내 추측.

편집 : 위의 경우, 여전히 파일 조각화로 인해 10GB가 손실되는 것처럼 보입니다. 조각 모음을 수행하는 동안 자동으로 수정되는 일반적인 파일 시스템 손상이 있다고 생각합니다. 대용량 조각화뿐만 아니라 저장 공간을 차지하는 파일을 부분적으로 삭제했다고 생각합니다. 해당 조각 모음 (또는 조각 모음 전에 scandisk 실행)에서 디스크 검사 로그를 보는 것이 좋을 것입니다.

— 제임스 티 스넬
소스

추신-그것은 하드 코어 조각화 였을 것입니다.

— 제임스 T 스넬

조각 모음 후 스토리지 소비가 증가한 유효한 이유인지는 모르겠습니다. 그러나이 사실을 여러 번 발견했습니다. 시스템 복원 지점이 꽤 오래된 경우 (일반적으로 디스크 정리 유틸리티를 정기적으로 실행하면 발생하지 않음) C 드라이브에 많은 데이터가 수집 된 후 조각 모음이 발생합니다. 메모리 소비는 어느 곳에서나 증가하지만 해당 복원 지점을 삭제하면 점유 된 스토리지가 정리됩니다. 기술적으로는 말이되지 않지만 시간이 지나면 복원 지점이 메모리를 차지하므로 여러 번 발생했습니다.

— Kushal

Dunno, 10G는 많은 것처럼 보이지만 IME, 매우 가득 찬 디스크는 조각난 디스크보다 훨씬 빨리 조각화되는 경향이 있습니다. 만약 그가 85 % 이전에 있었다면 (그것은 85GiB이지만 100GB 디스크를 의미했기 때문에) 아마도 더 꽉 찼을 것입니다.

— Bernd Haug

해당 볼륨의 블록 크기가 외설적으로 높지 않으면 조각을 추적하지 않고 10GB의 공간이 확보되는 것을 개인적으로 믿을 수 없습니다. 블록 크기가 4096k이고 각 프래그먼트가 추적하기 위해 전체 블록이 필요하다고 가정하면 (거짓), 이전에는 추적 된 250 만 개의 프래그먼트 가 필요 하지만 더 많은 공간을 확보하기 위해 더 이상 필요 하지 않습니다.

— CarlF

@Doc-포인터는 전체 블록을 사용하지 않습니다. 각 할당 블록이 여러 섹터 인 경우 데이터를 추적 할 블록 수가 적으므로 더 적은 포인터가 필요하므로 모든 조각을 추적하는 데 가능한 최대 오버 헤드는 3 % 미만입니다. NTFS의 정확한 세부 사항을 모르지만 (비효율적 인) FAT 파일 시스템을 사용하면 FAT의 이름을 딴 파일 할당 테이블 (이 조각 추적 포인터)에 대해 10 %의 오버 헤드를 얻을 수 없습니다.

— Steve314