NTFS는 어떤 블록 할당 알고리즘을 사용합니까?

Windows XP 64에서 1.2GB 파일을 다운로드했으며 이미지가 표시된 것처럼 조각났습니다. 불행히도, Piriform Defraggler에서 스냅 샷을 찍기 전에 다른 파일의 조각 모음을 수행 했으므로 파일이 작성된 시점의 정확한 상태를 볼 수 없습니다. 그러나 디스크는 항상 현재와 같이 비어 있었고 (25 % 사용) 조각난 것이 거의 없었습니다.

NTFS는 어떤 블록 할당 알고리즘을 사용합니까? 임의의 것처럼 보이거나 디스크 헤드가 실제로 서있는 곳에 놓을 수 있습니다.

최신 정보:

이것은 67MiB의 새 파일을 작성한 후 오늘 일어난 일입니다. 731 개의 조각으로 나뉘 었으며 평균 크기는 95KiB입니다. 이 파일은 약간의 틈새를 채우는 데 사용되었지만 전부는 아니지만 거대한 연속 여유 공간을 사용하지 않습니다. 이상하지 않습니까?

업데이트 2 :

PC Guru 와 달리 , 나는 오페라가 범인이라고 생각하지 않습니다. Google 크롬과 달리 Windows가 예상 크기를 알려주지 않는다고 생각하지만 불가능한 경우가 많으며 OS를 제대로 처리하는 것은 OS의 책임입니다. 다음 그림은이 파티션에서 거의 아무것도하지 않고 며칠 후에 일어난 일을 보여줍니다. TEMP 디렉토리와 모든 내 데이터 (Windows에서 관리하는 데이터 제외)는 모두 다른 곳에 있습니다. Windows 자체 SetEndOfFile는 자체 파일을 끔찍한 방식 으로 사용하지 않고 조각화합니다 (약 40MB의 작은 파일 몇 개에 600 개 조각). NTFS는 비어있는 디스크의 중간과 끝 부분에 파일이 다시 있기 때문에 사용 가능한 첫 번째 섹터를 사용하지 않는 것 같습니다 (사용률 23 %).

IIRC, NTFS 파일 시스템은 파일을 연속 저장소에 할당하려고합니다. 그러나 파일 시스템이 파일의 크기를 알고있는 경우에만 그렇게 할 수 있습니다. 파일을 열고 쓰기를 시작하면 파일에 맞는 "최상의"위치에 기록됩니다 (일반적으로 플래터 바깥 쪽). 그러나 그 "최상의"장소는 파일에 맞게 충분히 크지 않을 수 있습니다.

응용 프로그램에서 NTFS에 파일의 실제 크기 ( SetEndOfFile () 사용)를 알려 주면 NTFS는 파일 의 연속 공간을 찾는 데 더 나은 작업을 수행 할 수 있습니다 (SetEndOfFile API로 인해 NTFS가 전체 파일에 대한 저장소를 할당 함).

문제는 Opera와 관련이 있어야합니다. 방금 매우 가득 찬 조각난 드라이브에서 많은 파일을 보았습니다. Chrome을 사용하여 다운로드 한 대용량 파일은 모두 연속적입니다.

이는 Chrome이 다운로드 시작시 파일 크기를 알고 있으므로 NTFS에 예상되는 파일 크기를 알려줍니다. 그렇게하면 NTFS는 파일을 단일 조각에 넣거나 조각이 충분히 크지 않은 경우 사용 가능한 가장 큰 조각에 파일을 배치하려고합니다. 흥미롭게도 항상 이러한 조각을 내림차순으로 사용하므로 탐색기에서 조각난 드라이브에 복사 한 대용량 파일이 드라이브 전체에서 이동할 수 있습니다.

프로그램이 파일 크기를 알지 못하거나 NTFS에 신경 쓰지 않고 대신 파일을 열고 순차 데이터 쓰기를 시작하면 NTFS는 FAT32와 매우 유사하게 작동합니다. 해당 세션에서 마지막으로 할당 된 후 사용 가능한 첫 번째 것)은 이후 사용 가능한 모든 것을 사용합니다. 예를 들어, 거의 동시에 CCleaner에 레지스트리를 스캔하여 큰 txt ".Reg"파일로 백업하도록 요청했습니다. 이 파일은 드라이브 시작 근처에서 시작된 다음 127 개의 서로 다른 조각으로 분산되었습니다. 탐색기로 복사하거나 Chrome으로 다운로드 한 파일과 달리 내가 본 모든 파일에서 클러스터는 오름차순으로 할당되었습니다.

이 연구를 위해 Winhex (Winhex.com에서 제공하는 무료 평가판)를 사용했습니다. 디렉토리 항목을 볼 때 파일 이름을 마우스 오른쪽 버튼으로 클릭하고 위치, 클러스터 나열을 선택하여 해당 파일이 사용하는 클러스터 목록을 확인하십시오.