고급 형식(4K) 디스크 호환성 업데이트

플랫폼

클라이언트 Windows XP, Windows Vista, Windows 7, Windows 7 SP1, Windows 8
서버 Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016

설명

이 문서는 Windows 7 SP1 및 Windows Server 2008 R2 SP1용으로 릴리스된 512 바이트 에뮬레이션(512e) 디스크 호환성 업데이트라는 제목의 문서의 업데이트된 버전입니다. 이 업데이트에는 많은 새로운 정보가 포함되어 있으며, 그 중 일부는 Windows 8 및 Windows Server 2012에만 적용됩니다.

Areal 밀도는 매년 증가하고 있으며, 최근 3TB 디스크가 등장하면서 감소하는 SNR(신호 대 노이즈 비율)을 처리하는 데 사용되는 오류 수정 메커니즘이 공간 비효율적이 되고 있습니다. 즉, 미디어를 사용할 수 있도록 하려면 오버헤드가 증가해야 합니다. 이 오류 수정 메커니즘을 개선하기 위한 스토리지 업계 솔루션 중 하나는 더 큰 물리적 섹터 크기를 포함하는 다른 물리적 미디어 형식을 도입하는 것입니다. 이 새로운 물리적 미디어 형식을 고급 형식이라고 합니다. 따라서 최신 스토리지 디바이스의 섹터 크기에 대한 가정을 하는 것은 더 이상 안전하지 않으며, 개발자는 코드의 기반이 되는 가정을 연구하여 영향이 있는지 확인해야 합니다.

이 항목에서는 고급 형식 스토리지 디바이스가 소프트웨어에 미치는 영향을 소개하고, 이러한 유형의 미디어를 지원하기 위해 앱이 수행할 수 있는 작업을 설명하고, 개발자가 이러한 유형의 디바이스를 지원할 수 있도록 Microsoft가 Windows Vista, Windows 7 및 Windows 8과 함께 도입한 인프라에 대해 설명합니다. 이 항목에 제시된 자료는 고급 형식 디스크와의 호환성을 개선하기 위한 지침을 제공하지만, 이 정보는 일반적으로 Windows Vista, Windows 7 및 Windows 8을 실행하는 고급 형식 디스크가 있는 모든 시스템에 적용됩니다.

새로운 대규모 섹터 관련 기능 요약

아래 목록에는 대규모 섹터 디스크를 사용하는 고객 및 개발자 환경을 개선하는 데 도움이 되는 Windows 8 및 Windows Server 2012의 일부로 제공되는 새로운 기능이 요약되어 있습니다. 각 항목에 대한 자세한 설명은 다음과 같습니다.

• 에뮬레이션(512e)을 사용하는 4K 디스크에 대한 Windows 7 SP1 지원을 기반으로 하며, 에뮬레이션 없이 4K 섹터 크기(4K 네이티브)를 사용하는 디스크에 대한 전체 받은 편지함 지원을 제공합니다. 지원되는 일부 앱 및 시나리오는 다음과 같습니다.
  • 에뮬레이션 없이 4K 섹터 디스크에 Windows를 설치하고 부팅하는 기능(4K 네이티브 디스크)
  • VHD 및 새 VHDX 파일 형식
  • 전체 HyperV 지원
  • Windows 백업
  • NTFS(NT 파일 시스템)의 전체 지원
  • 새 저장소 공간 및 풀(SSP)을 사용하여 전체 지원
  • Windows Defender를 사용하여 전체 지원
• 물리적 섹터 크기(FileFsSectorSizeInformation)를 쿼리하는 새 API를 제공합니다.
  • 네트워크 볼륨에 사용 가능
  • 모든 파일 핸들에 발급할 수 있습니다.
  • 권한 없는 앱에 사용 가능
  • 친숙한 사용 모델
• 맞춤 정보를 사용하여 볼륨의 논리적 및 물리적 섹터 크기를 쿼리하는 향상된 fsutil 명령줄 유틸리티를 포함합니다(맞춤 정보가 없는 유틸리티의 기본 버전은 Microsoft KB 982018 Windows 7 및 Microsoft KB 982018 Windows Server 2008 R2에서 사용할 수 있음)

4K(고급 형식) 디스크 소개

미디어 형식의 이러한 변경을 도입하는 문제 중 하나는 기존 소프트웨어 및 하드웨어와 호환성 문제를 도입할 가능성이 있다는 것입니다. 임시 호환성 솔루션으로 스토리지 업계는 처음에는 일반 512바이트 섹터 디스크를 에뮬레이트하지만 표준 ATA 및 SCSI 명령을 통해 실제 섹터 크기에 대한 정보를 제공하는 디스크를 도입했습니다. 이 에뮬레이션의 결과로 기본적으로 두 섹터 크기가 있습니다.

논리 섹터: 미디어에 대한 논리 블록 주소 지정에 사용되는 단위입니다. 또한 이를 스토리지가 허용할 수 있는 가장 작은 쓰기 단위로 생각할 수도 있습니다. 에뮬레이션입니다.
물리적 섹터: 디바이스에 대한 읽기 및 쓰기 작업이 단일 작업으로 완료되는 단위입니다. 원자성 쓰기 단위입니다.
IOCTL_DISK_GET_DRIVE_GEOMETRY 같은 대부분의 최신 Windows API는 논리 섹터 크기를 반환하지만 STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR 구조의 BytesPerPhysicalSector 필드에 포함된 관련 정보를 사용하여 IOCTL_STORAGE_QUERY_PROPERTY 제어 코드를 통해 실제 섹터 크기를 검색할 수 있습니다. 이 내용은 이 문서의 뒷부분에서 자세히 설명합니다.

대규모 섹터 미디어의 초기 유형

스토리지 업계는 4KB 물리적 섹터 크기의 미디어를 위해 이 새로운 고급 형식 스토리지 유형으로 전환하기 위한 노력을 빠르게 강화하고 있습니다. 두 가지 유형의 미디어가 시장에 출시될 예정입니다.

4KB 네이티브: 이 미디어에는 에뮬레이션 계층이 없으며 4KB를 논리적 및 물리적 섹터 크기로 직접 노출합니다. 이 새로운 유형의 미디어의 전반적인 문제는 대부분의 앱과 운영 체제가 I/O를 쿼리하고 실제 섹터 크기에 맞추지 않아 예기치 않은 I/O 실패가 발생할 수 있다는 것입니다.
512바이트 에뮬레이션(512e): 이 미디어에는 이전 섹션에서 설명한 대로 에뮬레이션 계층이 있으며 512바이트를 논리 섹터 크기(현재 일반 디스크와 유사)로 노출하지만 실제 섹터 크기 정보(4KB)를 사용할 수 있습니다. 이 새로운 유형의 미디어의 전반적인 문제는 대부분의 앱 및 운영 체제가 물리적 섹터 크기의 존재를 이해하지 못하기 때문에 아래에 설명된 것처럼 많은 문제가 발생할 수 있다는 것입니다.
대규모 섹터 미디어에 대한 전체 Windows 지원

이 표에서는 다양한 미디어에 대한 공식 Microsoft 지원 정책과 그 결과 보고된 섹터 크기를 설명합니다. 자세한 내용은 이 KB 문서를 참조하세요.

일반 이름	보고된 논리 섹터 크기	보고된 물리적 섹터 크기	지원되는 Windows 버전
512 바이트 네이티브, 512n	512바이트	512바이트	모든 Windows 버전
고급 형식, 512e, AF, 512 바이트 에뮬레이션	512바이트	4KB	MS KB 2553708 있는 Windows Vista Windows Server 2008* w/MS KB 2553708 WINDOWS 7 w/ MS KB 982018 WINDOWS Server 2008 R2* w/ MS KB 982018 Windows 7 SP1 이상의 모든 Windows 버전. Server 2008 R2 SP1 이상의 모든 서버 버전 *Hyper-V를 제외하고. "대규모 섹터 드라이브에 대한 애플리케이션 지원 요구 사항" 섹션을 참조하세요.
고급 형식, AF, 4K 네이티브, 4Kn	4KB	4KB	Windows 8 이상의 모든 Windows 버전 Windows Server 2012 이상의 모든 서버 버전
기타	4KB 또는 512바이트 아님	4KB 또는 512바이트 아님	지원되지 않음

참고 항목

앞의 표에서는 강조되지 않지만 Windows XP, Windows Server 2003 및 Windows Server 2003 R2는 512e 또는 4Kn 미디어를 지원하지 않습니다. 시스템이 부팅되어 최소로 작동할 수 있지만 기능 문제, 데이터 손실 또는 최적이 아닐 경우의 시나리오는 알 수 없습니다. 따라서 Microsoft는 Windows XP 또는 Windows XP 코드베이스를 기반으로 하는 다른 제품(예: Windows Home Server 1.0, Windows Server 2003, Windows Server 2003 R2, Windows XP 64비트 버전, Windows XP Embedded, Windows Small Business Server 2003 및 Windows Small Business Server 2003 R2)에서 512e 미디어를 사용하지 않도록 강력히 주의합니다.

에뮬레이션 작동 방식: RMW(read-modify-write)

스토리지 매체에는 물리적 매체를 수정할 수 있는 특정 단위가 있습니다. 즉, 미디어를 실제 섹터 크기의 단위로만 작성하거나 다시 작성할 수 있습니다. 따라서 이 단위 수준에서 수행되지 않는 쓰기에는 추가 단계가 필요하며 아래 예제를 안내합니다.

이 시나리오에서 앱은 512 바이트 논리 섹터 내에 있는 Datastor 레코드의 콘텐츠를 업데이트해야 합니다. 이 다이어그램은 스토리지 디바이스가 쓰기를 완료하는 데 필요한 단계를 보여 줍니다.

위에서 설명한 것처럼 이 프로세스에는 성능 손실을 초래할 수 있는 스토리지 디바이스의 일부 작업이 포함됩니다. 이 추가 작업을 방지하려면 앱을 다음으로 업데이트해야 합니다.

• 실제 섹터 크기에 대한 쿼리
• 쓰기가 보고된 실제 섹터 크기에 맞춰지도록 합니다.

처음에는 성능 문제일 수 있지만 더 심각한 문제가 있을 수 있습니다. 다음 섹션에서 이에 대해 설명해 보겠습니다.

복원력: 읽기-수정-쓰기의 숨겨진 비용

복원력은 세션 간에 상태를 복구하는 앱의 기능을 말합니다. 512e 스토리지 디바이스가 512 바이트 섹터 쓰기 읽기-수정-쓰기 주기를 수행하는 데 필요한 사항을 확인했습니다. 미디어에서 이전 물리적 섹터를 덮어쓰는 프로세스가 중단된 경우 어떤 일이 일어나는지 살펴보겠습니다. 그 결과는 어땠을까요?

• 대부분의 하드 디스크 드라이브가 현재 위치에서 업데이트되기 때문에 물리적 섹터인 물리적 섹터는 부분 덮어쓰기로 인해 불완전한 정보로 인해 미디어 부분이 손상되었을 수 있습니다. 다른 방법으로, 8개의 논리 섹터(물리적 섹터에 논리적으로 포함됨)가 모두 손실될 수 있다고 생각할 수 있습니다.
• 데이터 저장소가 있는 대부분의 앱은 미디어 오류에서 복구할 수 있는 기능으로 설계되어 있지만, 8개 섹터가 손실되거나 8개의 커밋 레코드가 손실되면 데이터 저장소가 정상적으로 복구할 수 없게 될 수 있습니다. 관리자는 백업에서 데이터베이스를 수동으로 복원해야 하거나 긴 다시 빌드를 수행해야 할 수도 있습니다.
• 한 가지 더 중요한 영향은 읽기-수정-쓰기 주기를 유발하는 다른 앱의 동작으로 인해 앱이 실행되지 않더라도 데이터가 손실될 수 있다는 것입니다. 이는 단순히 데이터와 다른 앱의 데이터가 동일한 물리적 섹터 내에 있을 수 있기 때문입니다.

이를 염두에 두고 앱 소프트웨어는 코드에서 가져온 모든 가정을 재평가하고 논리적 물리적 섹터 크기 구분과 이 문서의 뒷부분에서 설명한 몇 가지 흥미로운 고객 시나리오를 인식하는 것이 중요합니다.

올바른 작업 수행(읽기-수정-쓰기 방지)

일부 스토리지 공급업체는 읽기-수정-쓰기 주기의 성능 및 복원력 문제를 완화하기 위해 특정 512e 스토리지 디바이스 내에서 일부 수준의 완화를 도입할 수 있지만 워크로드 측면에서 처리할 수 있는 완화는 매우 많습니다. 따라서 앱은 이 완화를 장기적인 솔루션으로 사용해서는 안 됩니다. 또한 모든 디스크 클래스가 이러한 완화를 구현할 것이라는 보장은 없으며 완화가 잘 설계되었다는 보장도 없습니다.

이에 대한 해결책은 드라이브 내 완화가 아니라 이러한 유형의 미디어를 지원하는 데 도움이 되는 올바른 일련의 작업을 수행하는 앱을 디자인하는 것입니다. 이 섹션에서는 앱에 큰 섹터 디스크에 문제가 있을 수 있는 일반적인 시나리오에 대해 설명하고 각 문제를 시도하고 해결하기 위한 조사 방법을 제안합니다.

문제 1: 파티션이 실제 섹터 경계에 정렬되지 않음

관리자/사용자가 디스크를 분할할 때 첫 번째 파티션이 정렬된 경계에 만들어지지 않았을 수 있습니다. 이로 인해 모든 후속 쓰기가 물리적 섹터 경계에 정렬되지 않을 수 있습니다. Windows Vista SP1 및 Windows Server 2008을 기준으로 첫 번째 파티션은 4KB 물리적 섹터 경계에 맞춰진 디스크의 첫 번째 1024KB(디스크 4GB 이상, 그렇지 않으면 맞춤은 64KB)에 배치됩니다. 그러나 Windows XP의 기본 분할, 타사 분할 유틸리티 또는 잘못된 Windows API 사용량을 감안할 때 생성된 파티션은 실제 섹터 경계에 맞춰지지 않을 수 있습니다. 개발자는 올바른 API를 사용하여 맞춤을 보장해야 합니다. 파티션 맞춤을 확인하는 데 도움이 되는 권장 API는 아래에 설명되어 있습니다.

IVdsPack::CreateVolume 및 IVdsPack2::CreateVolume2 API는 새 볼륨을 만들 때 지정된 맞춤 매개 변수를 사용하지 않고 운영 체제에 대한 맞춤 값 기본값을 사용합니다(Windows Vista SP1 이전 버전에서는 63바이트를 사용하고 Windows Vista SP1이 위에 명시된 기본값을 사용합니다). 대신 파티션을 만들어야 하는 앱에 대해 지정된 맞춤 매개 변수를 사용하는 IVdsCreatePartitionEx::CreatePartitionEx 또는 IVdsAdvancedDisk::CreatePartition API를 사용합니다.

맞춤이 올바른지 확인하는 가장 좋은 방법은 파티션을 처음 만들 때 올바르게 수행하는 것입니다. 그렇지 않으면 앱은 쓰기를 수행할 때 또는 초기화 시 매우 복잡한 프로세스일 수 있는 맞춤을 고려해야 합니다.

문제 2: 버퍼되지 않은 쓰기가 실제 섹터 크기에 맞지 않음

가장 간단한 문제는 버퍼되지 않은 쓰기가 스토리지 미디어의 보고된 실제 섹터 크기에 맞지 않는다는 것입니다. 반면 버퍼링된 쓰기는 우연히 1세대 대형 섹터 미디어의 물리적 섹터 크기인 페이지 크기 4KB에 맞춰집니다. 그러나 데이터 저장소가 있는 대부분의 앱은 버퍼되지 않은 쓰기를 수행하므로 이러한 쓰기가 실제 섹터 크기의 단위로 수행되는지 확인해야 합니다.

결과 앱 I/O가 정렬되지 않은 시나리오의 몇 가지 예:

커밋 레코드는 512바이트 섹터로 채워집니다. 데이터 저장소가 있는 앱에는 일반적으로 메타데이터 변경에 대한 정보를 유지 관리하거나 데이터 저장소의 구조를 유지하는 일종의 커밋 레코드가 있습니다. 섹터 손실이 여러 레코드에 영향을 주지 않도록 하기 위해 이 커밋 레코드는 일반적으로 섹터 크기로 채워집니다. 실제 섹터 크기가 큰 디스크를 사용하는 경우 앱은 이전 섹션에 표시된 대로 실제 섹터 크기를 쿼리하고 각 커밋 레코드가 해당 크기로 채워지도록 해야 합니다. 4K 디스크를 사용하면 I/O가 실패하지 않습니다. 512e 디스크를 사용하면 읽기-수정-쓰기 주기를 방지할 뿐만 아니라 물리적 섹터가 손실된 경우 커밋 레코드가 하나만 손실되도록 할 수 있습니다.
로그 파일은 정렬되지 않은 청크 로 작성됩니다. 버퍼링되지 않은 I/O는 일반적으로 로그 파일을 업데이트하거나 추가할 때 사용됩니다. 앱은 버퍼링된 I/O로 전환하거나 내부적으로 로그 업데이트를 실제 섹터 크기의 단위로 버퍼링하여 실패한 I/O를 방지하거나 읽기-수정-쓰기를 트리거할 수 있습니다.
앱에서 버퍼되지 않은 I/O가 발생하는지 확인하려면 CreateFile 함수를 호출할 때 dwFlagsAndAttributes 매개 변수에 FILE_FLAG_NO_BUFFERING 플래그를 포함해야 합니다.

또한 현재 쓰기를 섹터 크기에 맞추는 경우 미디어의 섹터 크기를 쿼리하는 대부분의 기존 API가 논리 섹터 크기인 주소 지정 단위를 쿼리하기 때문에 이 섹터 크기는 논리 섹터 크기일 가능성이 높습니다. 여기에 관심있는 섹터 크기는 원자성의 실제 단위인 물리적 섹터 크기입니다. 논리 섹터 크기를 검색하는 API의 몇 가지 예는 다음과 같습니다.

• GetDiskFreeSpace, GetDiskFreeSpaceEx
• FileFsVolumeInformation
• IOCTL_DISK_GET_DRIVE_GEOMETRY, IOCTL_DISK_GET_DRIVE_GEOMETRY_EX
• IVdsDisk::GetProperties, IVdsDisk3::GetProperties2

물리적 섹터 크기를 쿼리하는 방법은 다음과 같습니다.

Windows 8에 대한 기본 설정 방법

Windows 8을 통해 Microsoft는 개발자가 앱 내에서 4K 지원을 쉽게 통합할 수 있는 새로운 API를 도입했습니다. 이 새로운 API는 아래에 설명된 Windows Vista 및 Windows 7의 레거시 방법보다 훨씬 많은 수의 시나리오를 지원합니다. 이 API를 사용하면 다음과 같은 호출 시나리오를 사용할 수 있습니다.

• 권한 없는 앱에서 호출
• 유효한 파일 핸들 호출
• SMB2를 통해 원격 볼륨에서 파일 핸들 호출
• 간소화된 프로그래밍 모델

API는 다음과 같이 정의된 연결된 구조 FILE_FS_SECTOR_SIZE_INFORMATION 사용하여 새 정보 클래스 FileFsSectorSizeInformation 형식입니다.

typedef struct _FILE_FS_SECTOR_SIZE_INFORMATION {  
    ULONG LogicalBytesPerSector;  
    ULONG PhysicalBytesPerSectorForAtomicity;  
    ULONG PhysicalBytesPerSectorForPerformance;  
    ULONG FileSystemEffectivePhysicalBytesPerSectorForAtomicity;  
    ULONG Flags;  
    ULONG ByteOffsetForSectorAlignment;  
    ULONG ByteOffsetForPartitionAlignment;  
} FILE_FS_SECTOR_SIZE_INFORMATION, *PFILE_FS_SECTOR_SIZE_INFORMATION;

Windows 7 및 Windows Vista용 레거시 메서드

Windows Vista 및 Windows Server 2008에서는 AHCI 기반 스토리지 컨트롤러에 연결된 스토리지 디바이스의 실제 섹터 크기를 쿼리하는 API를 도입했습니다. Windows 7 및 Windows Server 2008 R2 SP1(또는 Microsoft 기술 자료 982018) 현재 이 지원은 Storport 기반 스토리지 컨트롤러로 확장됩니다. 앱이 볼륨의 물리적 섹터 크기를 쿼리하는 방법을 보여 주는 코드 샘플은 STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR 구조를 참조하세요.

위의 코드 샘플을 사용하면 볼륨의 물리적 섹터 크기를 가져올 수 있지만 일부 드라이버가 올바르게 서식이 지정된 데이터를 반환하지 않을 수 있으므로 이를 사용하기 전에 보고된 물리적 섹터 크기에 대한 몇 가지 기본적인 온전성 검사를 수행해야 합니다.

• 보고된 물리적 섹터 크기가 보고된 논리 섹터 크기인지 >확인합니다. 그렇지 않은 경우 앱은 보고된 논리 섹터 크기와 동일한 물리적 섹터 크기를 사용해야 합니다.
• 보고된 물리적 섹터 크기가 2의 힘인지 확인합니다. 그렇지 않은 경우 앱은 보고된 논리 섹터 크기와 동일한 물리적 섹터 크기를 사용해야 합니다.
• 실제 섹터 크기가 512바이트에서 4KB 사이의 전력 2 값인 경우 보고된 논리 섹터 크기로 반올림된 물리적 섹터 크기를 사용하는 것이 좋습니다.
• 실제 섹터 크기가 4KB보다 큰 power-of-two 값인 경우 해당 값을 사용하기 전에 이 시나리오를 처리하는 앱의 기능을 평가해야 합니다. 그렇지 않으면 4KB로 반올림된 실제 섹터 크기를 사용하는 것이 좋습니다.

이 IOCTL을 사용하여 물리적 섹터 크기를 가져오는 데는 몇 가지 제한 사항이 있습니다. 해당 항목은 다음을 수행합니다.

• 상승된 권한이 필요합니다. 앱이 권한으로 실행되고 있지 않으면 위에서 설명한 대로 Windows 서비스 애플리케이션을 작성해야 할 수 있습니다.
• SMB 볼륨을 지원하지 않습니다. 또한 이러한 볼륨에 대한 실제 섹터 크기 쿼리를 지원하기 위해 Windows 서비스 애플리케이션을 작성해야 할 수도 있습니다.
• 파일 핸들에 발급할 수 없음(볼륨 핸들에 IOCTL을 발급해야 함)

문제 3: 512 바이트 섹터를 사용하는 파일 형식

표준 파일 형식(예: VHD 1.0)을 사용하는 일부 앱에는 512바이트 섹터 크기를 가정하도록 하드 코딩된 파일이 있을 수 있습니다. 따라서 이 파일을 업데이트하고 쓰면 디바이스에서 읽기-수정-쓰기 주기가 발생하므로 잠재적으로 고객에게 성능 및 복원력 문제가 발생할 수 있습니다. 그러나 앱이 이러한 유형의 미디어에서 작동을 지원하는 방법이 있습니다. 예를 들면 다음과 같습니다.

• 버퍼링을 사용하여 쓰기가 실제 섹터 크기의 단위로 수행되도록 합니다.
• 보고된 실제 섹터 크기의 단위로 업데이트가 수행되도록 하는 데 도움이 되는 내부 읽기-수정-쓰기 구현
• 가능하면 패드는 안쪽 여백이 빈 공간으로 해석되는 방식으로 물리적 섹터에 기록합니다.
• 더 큰 섹터를 지원하여 앱 데이터 구조의 버전을 다시 디자인하는 것이 좋습니다.

문제 4: 보고된 실제 섹터 크기가 세션 간에 변경될 수 있습니다.

Datastor를 호스트하는 기본 스토리지의 보고된 실제 섹터 크기가 변경될 수 있는 많은 시나리오가 있습니다. 가장 일반적인 것은 Datastor를 다른 볼륨으로 마이그레이션하거나 네트워크를 통해 마이그레이션하는 경우입니다. 보고된 실제 섹터 크기가 변경되면 많은 앱에서 예기치 않은 이벤트가 발생할 수 있으며 일부 앱이 다시 초기화되지 않을 수 있습니다.

이는 지원하는 가장 쉬운 시나리오가 아니며 여기에서 권고로 언급됩니다. 4K 네이티브 또는 512e 미디어를 사용하여 고객이 부정적인 영향을 받지 않도록 고객의 이동성 요구 사항을 고려하고 그에 따라 지원을 조정해야 합니다.

사용자가 볼륨의 논리적 및 물리적 섹터 크기를 검색하는 방법

Windows를 사용하는 기본 제공 유틸리티는 볼륨에 대한 섹터 크기 정보를 표시하는 유틸리티입니다. 지원되는 fsutil을 사용하는 Windows 버전은 다음과 같습니다.

• Windows 8
• Windows Server 2012
• Microsoft KB 982018 Windows 7 SP1
• Microsoft KB 982018 Windows 7
• Microsoft KB 982018(v3)를 사용하는 Windows Server 2008 R2 SP1
• Microsoft KB 982018(v3)를 사용하는 Windows Server 2008 R2
• Microsoft KB 2553708 Windows Vista
• Microsoft KB 2553708 Windows Server 2008

섹터 크기 정보를 얻으려면 관리자 권한 명령 프롬프트에서 다음과 같이 유틸리티를 호출합니다.

fsutil fsinfo ntfsinfo <drive letter>

512바이트 에뮬레이션이 있는 4K 섹터 디스크에는 다음과 같이 섹터당 바이트 필드가 512로 설정되고 실제 섹터당 바이트 필드가 4096으로 설정됩니다.

4K 네이티브 디스크에는 다음과 같이 섹터당 바이트 및 실제 섹터당 바이트 필드가 모두 4096으로 설정됩니다.

참고 항목

실제 섹터별 바이트 필드에 지원되지 않음이 표시되면 스토리지 드라이버가 IOCTL_STORAGE_QUERY_PROPERTY 지원하지 않거나 정보를 검색하는 동안 오류가 발생했습니다.

리소스

• Windows 일반 지원 문
• Microsoft KB 982018
• Windows 7 및 Windows Server 2008 R2용 핫픽스
• HyperV 지원 문
• IOCTL_STORAGE_QUERY_PROPERTY 제어 코드에 대한 일반 정보
• IOCTL_STORAGE_QUERY_PROPERTY 제어 코드
• STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR 구조체에 대한 일반 정보
• Microsoft 소프트웨어 업데이트를 설명하는 데 사용되는 표준 용어에 대한 설명
• IOCTL_STORAGE_QUERY_PROPERTY 제어 코드를 호출할 때 STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR 구조에서 보고된 스토리지 액세스 맞춤 정보를 추출하는 방법에 대한 세부 정보가 포함된 WDK 샘플 코드
• ImageX 명령줄 옵션에 대한 일반 정보
• 4KB 섹터 드라이브를 지원하기 위한 인텔 칩셋 드라이버 요구 사항