다음을 통해 공유

512바이트 에뮬레이션(512e) 디스크 호환성 업데이트

  • 아티클

플랫폼

클라이언트 - Windows Vista, Windows 7, Windows 7 SP1
서버 - Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1

기능 영향

심각도 - 높음
빈도 - 높음

설명

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

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

  • Microsoft KB 982018 Windows 7
  • Windows 7 SP1
  • Microsoft KB 982018 Windows Server 2008 R2
  • Windows Server 2008 R2 SP1
  • Microsoft KB 2553708 Windows Vista
  • Microsoft KB 2553708 Windows Server 2008

자세한 내용은 Windows의 대규모 섹터 드라이브에 대한 Microsoft 지원 정책에 대한 정보를 참조 하세요.

고급 형식 디스크에 대한 자세한 내용은 스토리지 공급업체에 문의하세요.

논리 및 물리적 섹터 크기

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

  • 논리 섹터: 미디어의 논리 블록 주소 지정에 사용되는 단위입니다. 또한 이를 스토리지가 허용할 수 있는 가장 작은 쓰기 단위로 생각할 수도 있습니다. 에뮬레이션입니다.

  • 물리적 섹터: 디바이스에 대한 읽기 및 쓰기 작업이 단일 작업으로 완료되는 단위입니다. 원자성 쓰기 단위입니다.

IOCTL_DISK_GET_DRIVE_GEOMETRY 같은 대부분의 최신 Windows API는 논리 섹터 크기를 반환하지만 STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR 구조의 BytesPerPhysicalSector 필드에 포함된 관련 정보를 사용하여 IOCTL_STORAGE_QUERY_PROPERTY 제어 코드를 통해 물리적 섹터 크기를 검색할 수 있습니다. 이 내용은 이 문서의 뒷부분에서 자세히 설명합니다.

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

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

  • 4KB 네이티브: 이 미디어에는 에뮬레이션 계층이 없으며 4KB를 논리적 및 물리적 섹터 크기로 직접 노출합니다. 이 미디어는 현재 Windows 및 대부분의 다른 운영 체제에서 지원되지 않습니다. 그러나 Microsoft는 향후 버전의 Windows에서 이러한 유형의 미디어를 지원하는 것이 타당성에 대한 조사를 수행하고 있으며, 적절한 경우 기술 자료 문서를 발행할 예정입니다.
  • 512바이트 에뮬레이션(512e): 이 미디어에는 이전 섹션에서 설명한 대로 에뮬레이션 계층이 있으며 512바이트를 논리 섹터 크기(현재 일반 디스크와 유사)로 노출하지만 실제 섹터 크기 정보(4KB)를 사용할 수 있습니다. 이것은 여러 스토리지 공급 업체가 현재 시장에 도입하는 것입니다. 이 새로운 유형의 미디어와 관련된 이 전반적인 문제는 대부분의 애플리케이션 및 운영 체제가 물리적 섹터 크기의 존재를 이해하지 못하기 때문에 아래에 설명된 것처럼 많은 문제가 발생할 수 있다는 것입니다.

에뮬레이션 작동 방식: RMW(Read-Modify-Write)

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

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

512 바이트 논리 섹터 내에서 데이터 저장소 레코드를 업그레이드하는 데 필요한 단계

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

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

읽기-수정-쓰기의 복원력 영향

복원력은 애플리케이션이 세션 간에 상태를 복구하는 기능을 말합니다. 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를 대신 사용하는 것이 좋습니다.

맞춤이 올바른지 확인하는 가장 좋은 방법은 파티션을 처음 만들 때 올바르게 수행하는 것입니다. 그렇지 않으면 애플리케이션이 쓰기를 수행하거나 초기화할 때 조정을 고려해야 합니다. 이는 매우 복잡한 문제일 수 있습니다. Windows Vista SP1에서는 일반적으로 문제가 되지 않습니다. 그러나 이전 버전의 Windows는 일부 고급 형식 디스크에서 성능 문제를 일으킬 수 있는 정렬되지 않은 파티션을 만들 수 있습니다.

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

기본 문제는 버퍼링되지 않은 쓰기가 스토리지 미디어의 보고된 실제 섹터 크기에 맞지 않아 드라이브에서 읽기-수정-쓰기가 트리거되어 성능 문제가 발생할 수 있다는 것입니다. 반면 버퍼링된 쓰기는 4KB의 페이지 크기에 맞춰 정렬됩니다. 이는 우연히 대규모 섹터 미디어의 1세대 물리적 섹터 크기입니다. 그러나 데이터 저장소가 있는 대부분의 애플리케이션은 버퍼되지 않은 쓰기를 수행하므로 이러한 쓰기가 실제 섹터 크기의 단위로 수행되는지 확인해야 합니다.

애플리케이션에서 버퍼링되지 않은 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

물리적 섹터 크기를 쿼리하는 방법

애플리케이션이 볼륨의 물리적 섹터 크기를 쿼리하는 방법을 보여 주는 코드 샘플은 다음을 참조하세요 https://msdn.microsoft.com/library/ff800831.aspx.

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

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

이 IOCTL을 사용하여 물리적 섹터 크기를 가져오는 데는 몇 가지 제한 사항이 있습니다.

  • 상승된 권한이 필요합니다. 애플리케이션이 권한으로 실행되지 않는 경우 위에서 설명한 대로 Windows 서비스 애플리케이션을 작성해야 할 수 있습니다.

  • SMB 볼륨을 지원하지 않습니다. 또한 이러한 볼륨에 대한 실제 섹터 크기 쿼리를 지원하기 위해 Windows 서비스 애플리케이션을 작성해야 할 수도 있습니다.

  • 파일 핸들에 발급할 수 없습니다(IOCTL은 볼륨 핸들에 발급되어야 함).

  • 이 문서의 시작 부분에 나열된 Windows 버전에서만 지원됩니다.

커밋 레코드는 512바이트 섹터로 채워집니다.

데이터 저장소가 있는 애플리케이션에는 일반적으로 메타데이터 변경 내용에 대한 정보를 유지 관리하거나 데이터 저장소의 구조를 유지하는 커밋 레코드 형식이 있습니다. 섹터 손실이 여러 레코드에 영향을 주지 않도록 하기 위해 이 커밋 레코드는 일반적으로 섹터 크기로 채워집니다. 물리적 섹터 크기가 큰 디스크를 사용하는 경우 애플리케이션은 이전 섹션에 표시된 대로 물리적 섹터 크기를 쿼리하고 각 커밋 레코드가 해당 크기로 채워지도록 해야 합니다. 이렇게 하면 읽기-수정-쓰기 주기가 방지될 뿐만 아니라 물리적 섹터가 손실된 경우 커밋 레코드가 하나만 손실되도록 할 수 있습니다.

로그 파일은 정렬되지 않은 청크로 기록됩니다.

버퍼링되지 않은 I/O는 일반적으로 로그 파일을 업데이트하거나 추가할 때 사용됩니다. 이러한 업데이트가 올바르게 정렬되도록 하는 몇 가지 방법이 있습니다.

  • 내부적으로 운영 미디어의 보고된 물리적 섹터 크기에 대한 로그 업데이트를 버퍼링하고, 실제 섹터 단위가 가득 찬 경우에만 로그 쓰기를 실행합니다.
  • 버퍼링된 I/O 사용

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

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

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

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

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

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

4KB 네이티브 미디어

512바이트 에뮬레이션 미디어는 512바이트 네이티브 미디어와 4KB 네이티브 미디어 간의 전환 단계로, 512e를 사용할 수 있게 된 직후 4KB 네이티브 미디어가 출시될 것으로 예상됩니다. 이 미디어에는 다음과 같은 몇 가지 중요한 의미가 있습니다.

  • 논리적 및 물리적 섹터 크기는 모두 4KB입니다.
  • 에뮬레이션 계층이 없으므로 스토리지에서 정렬되지 않은 쓰기가 실패합니다.
  • 숨겨진 복원력 적중 없음 - 애플리케이션이 작동하거나 작동하지 않음

Microsoft는 현재 향후 버전의 Windows에서 이러한 유형의 미디어에 대한 지원을 조사하고 있으며 적절한 경우 KB 문서를 발행할 예정이지만, 애플리케이션 개발자는 이러한 유형의 미디어에 대한 지원을 선제적으로 제공하는 것을 고려해야 합니다.

Closing

이 문서에서는 많은 일반적인 배포 시나리오에서 대규모 섹터 미디어가 도입하는 영향에 대해 설명했습니다. Read-Modify-Write의 성능 및 복원력 영향, 이 미디어가 도입할 수 있는 흥미로운 시나리오 중 일부 및 소프트웨어로 인해 발생할 수 있는 문제 집합을 확인하여 최종 사용자에게 궁극적으로 영향을 줍니다. 스토리지 산업은 더 큰 섹터 크기의 미디어로 빠르게 전환되고 있으며, 곧 고객은 기존의 512 바이트 섹터 크기의 디스크를 구입할 수 없게 될 것입니다.

이 문서는 살아있는 문서이며 개발자가 이러한 전환을 이해하는 데 도움을 주기 위한 것입니다. 고객, IT 전문가 및 하드웨어 공급업체와 각 조직과 대화를 시작하여 대규모 섹터 전환과 중요한 시나리오에 미치는 영향에 대해 이야기해야 합니다.