파일 조각 모음

  • 아티클

파일을 디스크에 쓸 때 인접한 클러스터에 파일을 쓸 수 없는 경우가 있습니다. 클러스터가 인접하지 않으면 파일을 읽고 쓰는 프로세스의 속도가 느려집니다. 디스크에서 인접하지 않은 클러스터가 더 멀리 떨어져 있을수록 하드 디스크 드라이브의 읽기/쓰기 헤드를 이동하는 데 걸리는 시간 때문에 문제가 더 심각해집니다. 인접하지 않은 클러스터가 있는 파일은 조각화됩니다. 파일을 최적화하여 빠르게 액세스하려면 볼륨을 조각 모음할 수 있습니다.

조각 모음은 디스크에서 파일의 일부를 이동하여 파일을 조각 모음하는 프로세스입니다. 즉, 디스크에서 파일 클러스터를 이동하여 인접하도록 만드는 프로세스입니다. 자세한 내용은 다음 섹션을 참조하세요.

파일 조각 모음

단순한 단일 작업 운영 체제에서는 조각 모음 소프트웨어가 유일한 작업이며 디스크에서 읽거나 쓰는 다른 프로세스가 없습니다. 그러나 멀티태스킹 운영 체제에는 하드 디스크 드라이브에서 읽거나 쓰는 프로세스와 해당 하드 디스크 드라이브를 조각 모음하는 프로세스가 있습니다. 요령은 쓰기 프로세스를 매우 오랫동안 중지하지 않고 조각 모음 중인 파일에 쓰기를 방지하는 것입니다. 이 문제를 해결하는 것은 간단하지 않지만 가능합니다.

파일 시스템 디스크 구조에 대한 자세한 지식이 없어도 조각 모음을 수행할 수 있도록 세 개의 제어 코드 세트가 제공됩니다. 컨트롤 코드는 다음과 같은 기능을 제공합니다.

  • 애플리케이션이 빈 클러스터를 찾을 수 있도록 설정
  • 파일 클러스터의 디스크 위치 확인
  • 디스크에서 클러스터 이동

또한 제어 코드는 이동 중에 파일에서 읽고 쓰는 다른 프로세스를 금지하고 허용하는 문제를 투명하게 처리합니다.

다른 프로세스의 실행을 금지하지 않고도 이러한 작업을 수행할 수 있습니다. 그러나 디스크 드라이브를 조각 모음하는 동안 다른 프로세스의 응답 시간은 느려집니다.

파일을 조각 모음하려면

  1. FSCTL_GET_VOLUME_BITMAP 제어 코드를 사용하여 볼륨에서 전체 파일을 수용할 만큼 충분히 큰 위치를 ​​찾습니다.

    참고

    필요한 경우 다른 파일을 이동하여 충분히 큰 위치를 만드세요. 이상적으로는 파일의 첫 번째 익스텐트 뒤에 할당되지 않은 클러스터가 충분하여 후속 익스텐트를 첫 번째 익스텐트 뒤의 공간으로 이동할 수 있습니다.

     

  2. FSCTL_GET_RETRIEVAL_POINTERS 제어 코드를 사용하여 디스크에 있는 파일의 현재 레이아웃 맵을 가져옵니다.

  3. FSCTL_GET_RETRIEVAL_POINTERS에서 반환된 RETRIEVAL_POINTERS_BUFFER 구조체를 살펴봅니다.

  4. 구조체를 살펴볼 때 FSCTL_MOVE_FILE 제어 코드를 사용하여 각 클러스터를 이동합니다.

    참고

    다른 프로세스가 디스크에 쓸 때마다 비트맵이나 검색 구조 또는 둘 다를 갱신해야 할 수 있습니다.

     

조각 모음 프로세스에 사용되는 두 가지 작업에는 볼륨에 대한 핸들이 필요합니다. 관리자만 볼륨에 대한 핸들을 가져올 수 있으므로 관리자만 볼륨을 조각 모음할 수 있습니다. 애플리케이션은 조각 모음 소프트웨어를 실행하려는 사용자의 권한을 확인해야 하며 사용자에게 적절한 권한이 없는 경우 사용자가 볼륨을 조각 모음하도록 허용해서는 안 됩니다.

FAT 또는 FAT32 파일 시스템 볼륨을 조각 모음하는 동안 CreateFile을 사용하여 디렉터리를 여는 경우 GENERIC_READ 액세스 마스크 값을 지정합니다. MAXIMUM_ALLOWED 액세스 마스크 값을 지정하지 마세요. 지정할 경우 디렉터리에 대한 액세스가 거부됩니다.

클러스터 반올림 파일 크기를 초과하여 확장되는 NTFS 파일 시스템에서 할당된 클러스터를 이동하려고 시도하지 마세요. 결과는 오류입니다.

NTFS 파일 시스템 볼륨의 재분석 지점, 비트맵 및 특성 목록을 조각 모음하고, 읽기 및 동기화를 위해 열고, file:name:type 구문을 사용하여 이름을 지정할 수 있습니다. 예를 들어 dirname:$i30:$INDEX_ALLOCATION, mrp::$DATA, mrp::$REPARSE_POINT 및 mrp::$ATTRIBUTE_LIST입니다.

NTFS 파일 시스템 볼륨을 조각 모음하는 경우 파일의 할당 크기를 초과하는 가상 클러스터를 조각 모음할 수 있습니다.

조각 모음과 섀도 복사본 간 상호 작용 최소화

가능하면 서로 상대적으로 정렬된 블록의 데이터를 16KB(킬로바이트) 단위로 이동합니다. 이렇게 하면 다음 조건이 발생할 때 섀도 복사본 공간이 증가하고 성능이 저하되므로 섀도 복사본이 활성화된 경우 쓰기 시 복사 오버헤드가 줄어듭니다.

  • 이동 요청 블록 크기가 16KB보다 작거나 같습니다.
  • 이동 델타가 16KB 단위가 아닙니다.

이동 델타는 원본 블록 시작과 대상 블록 시작 사이의 바이트 수입니다. 즉, X - Y의 절대값이 16KB의 짝수 배수인 경우 오프셋 X(디스크)에서 시작하는 블록을 시작 오프셋 Y로 이동할 수 있습니다. 따라서 4KB 클러스터를 가정하면 클러스터 3에서 클러스터 27로의 이동은 최적화되지만 클러스터 18에서 클러스터 24로의 이동은 최적화되지 않습니다. mod(3,4) = 3 = mod(27,4)입니다. 모드 4는 각각 4KB인 클러스터 4개가 16KB와 같기 때문에 선택됩니다. 따라서 16KB 클러스터 크기로 포맷된 볼륨에서는 모든 이동 파일이 최적화됩니다.

섀도 복사본에 대한 자세한 내용은 볼륨 섀도 복사본 서비스를 참조하세요.

조각 모음이 지원되는 파일, 스트림 및 스트림 형식

대부분의 파일은 FSCTL_MOVE_FILE 제어 코드를 사용하여 이동할 수 있지만 모든 파일을 이동할 수 있는 것은 아닙니다. 다음은 FSCTL_MOVE_FILE에서 지원하는 파일, 스트림 및 스트림 형식(특성 형식 코드라고도 함)의 목록입니다. 다른 파일, 스트림 및 스트림 형식은 FSCTL_MOVE_FILE에서 지원되지 않습니다.

모든 파일 또는 디렉터리에 대해 지원되는 스트림 형식입니다.

  • ::$DATA
  • ::$ATTRIBUTE_LIST
  • ::$REPARSE_POINT
  • ::$EA
  • ::$LOGGED_UTILITY_STREAM

**Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003 및 Windows XP: **::$EA 및 ::$LOGGED_UTILITY_STREAM은 Windows 8 및 Windows Server 2012 이전 버전에서 지원되지 않습니다.

모든 디렉터리에 대해 지원되는 스트림 형식입니다.

  • ::$BITMAP
  • ::$INDEX_ALLOCATION

다음은 FSCTL_MOVE_FILE에서 “filename:streamname:$typename” 형식으로 지원하는 시스템 파일, 스트림 및 스트림 형식입니다.

  • $MFT::$DATA
  • $MFT::$ATTRIBUTE_LIST
  • $MFT::$BITMAP
  • $AttrDef::$DATA
  • $AttrDef::$ATTRIBUTE_LIST
  • $Secure:$SDS:$DATA
  • $Secure::$ATTRIBUTE_LIST
  • $Secure:$SDH:$INDEX_ALLOCATION
  • $Secure:$SDH:$BITMAP
  • $Secure:$SII:$INDEX_ALLOCATION
  • $Secure:$SII:$BITMAP
  • $UpCase::$DATA
  • $UpCase::$ATTRIBUTE_LIST
  • $Extend:$I30:$INDEX_ALLOCATION
  • $Extend::$ATTRIBUTE_LIST
  • $Extend:$I30:$BITMAP
  • $Extend\$UsnJrnl:$J:$DATA
  • $Extend\$UsnJrnl::$ATTRIBUTE_LIST
  • $Extend\$UsnJrnl:$Max:$DATA
  • $Extend\$Quota:$Q:$INDEX_ALLOCATION
  • $Extend\$Quota::$ATTRIBUTE_LIST
  • $Extend\$Quota:$Q:$BITMAP
  • $Extend\$Quota:$O:$INDEX_ALLOCATION
  • $Extend\$Quota:$O:$BITMAP
  • $Extend\$ObjId:$O:$INDEX_ALLOCATION
  • $Extend\$ObjId::$ATTRIBUTE_LIST
  • $Extend\$ObjId:$O:$BITMAP
  • $Extend\$Reparse:$R:$INDEX_ALLOCATION
  • $Extend\$Reparse::$ATTRIBUTE_LIST
  • $Extend\$Reparse:$R:$BITMAP
  • $Extend\$RmMetadata:$I30:$INDEX_ALLOCATION
  • $Extend\$RmMetadata:$I30:$BITMAP
  • $Extend\$RmMetadata::$ATTRIBUTE_LIST
  • $Extend\$RmMetadata\$Repair::$DATA
  • $Extend\$RmMetadata\$Repair::$ATTRIBUTE_LIST
  • $Extend\$RmMetadata\$Repair:$Config:$DATA
  • $Extend\$RmMetadata\$Txf:$I30:$INDEX_ALLOCATION
  • $Extend\$RmMetadata\$Txf::$ATTRIBUTE_LIST
  • $Extend\$RmMetadata\$Txf:$I30:$BITMAP
  • $Extend\$RmMetadata\$Txf:$TXF_DATA:$LOGGED_UTILITY_STREAM
  • $Extend\$RmMetadata\$TxfLog:$I30:$INDEX_ALLOCATION
  • $Extend\$RmMetadata\$TxfLog::$ATTRIBUTE_LIST
  • $Extend\$RmMetadata\$TxfLog:$I30:$BITMAP
  • $Extend\$RmMetadata\$TxfLog\$Tops::$DATA
  • $Extend\$RmMetadata\$TxfLog\$Tops::$ATTRIBUTE_LIST
  • $Extend\$RmMetadata\$TxfLog\$Tops:$T:$DATA
  • $Extend\$RmMetadata\$TxfLog\$TxfLog.blf::$DATA
  • $Extend\$RmMetadata\$TxfLog\$TxfLog.blf::$ATTRIBUTE_LIST