進階格式 （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

描述

本文是標題為 512 位元組模擬 （512e） 磁碟相容性更新的更新版本，該更新版本已針對 Windows 7 SP1 和 Windows Server 2008 R2 SP1 發行。 此更新包含許多新資訊，其中有些僅適用於 Windows 8 和 Windows Server 2012。

平均密度逐年增加，隨著最近出現 3 TB 磁碟，用來處理減少訊號與雜訊比率 （SNR） 的錯誤修正機制正在變得空間效率低下：也就是說，需要增加的額外負荷，以確保媒體可供使用。 改善此錯誤修正機制的儲存產業解決方案之一，是引進不同的實體媒體格式，其中包含較大的實體扇區大小。 這個新的實體媒體格式稱為進階格式。 因此，對於新式存儲設備的扇區大小，開發人員必須研究其程式代碼基礎的假設，以判斷是否有影響，這已不再安全。

本主題介紹軟體上進階格式儲存裝置的效果、討論應用程式可協助支援這種類型的媒體，並討論 Windows Vista、Windows 7 和 Windows 8 引進 Microsoft的基礎結構，讓開發人員能夠支援這些類型的裝置。 雖然本主題中呈現的材料提供改善與進階格式磁碟相容性的指導方針，但資訊通常會套用至執行 Windows Vista、Windows 7 和 Windows 8 之進階格式磁碟的所有系統。

新大型扇區相關功能的摘要

下列清單摘要說明 Windows 8 和 Windows Server 2012 隨附的新功能，以協助改善大型扇區磁碟的客戶和開發人員體驗。 每個項目的詳細描述如下。

• 以具有仿真的 4K 磁碟的 Windows 7 SP1 支援為基礎建置 （512e），並提供具有 4K 扇區大小的磁碟完整收件匣支援，而不模擬 （4K 原生）。 支援應用程式與案例包括：
  • 在沒有模擬的情況下，從 4K 扇區磁碟安裝 Windows 和開機的能力 （4K 原生磁碟）
  • VHD 和新的 VHDX 檔案格式
  • 完整的 HyperV 支援
  • Windows 備份
  • NT 檔案系統的完整支援 （NTFS）
  • 新 儲存空間 和集區的完整支援（SSP）
  • Windows Defender 的完整支援
• 提供新的 API 來查詢實體扇區大小 （FileFsSectorSizeInformation）：
  • 適用於網路磁碟區
  • 可以發出給任何檔句柄
  • 適用於非特殊許可權的應用程式
  • 更方便的使用模型
• 包含增強的 fsutil 命令行公用程式，可查詢具有對齊資訊之磁碟區的邏輯和實體扇區大小（基本版的公用程式沒有對齊資訊，適用於具有 Microsoft KB 982018 的 Windows 7，以及具有 Microsoft KB 982018 的 Windows Server 2008 R2）

進階格式 （4K） 磁碟簡介

在媒體格式中引入這項變更的其中一個問題，就是可能引進現有軟體和硬體的相容性問題。 作為暫時相容性解決方案，記憶體產業一開始引進了模擬一般 512 位元組扇區磁碟的磁碟，但透過標準 ATA 和 SCSI 命令提供真實扇區大小的相關信息。 由於這種模擬，基本上有兩個扇區大小：

邏輯扇區： 用於媒體之邏輯區塊尋址的單位。 我們也可以將其視為記憶體可以接受的最小寫入單位。 這是模擬。
實體扇區： 在單一作業中完成對裝置的讀取和寫入作業單位。 這是不可部分完成寫入的單位。
最新的 Windows API，例如IOCTL_DISK_GET_DRIVE_GEOMETRY會傳回邏輯扇區大小，但實體扇區大小可透過IOCTL_STORAGE_QUERY_PROPERTY控件程式代碼擷取，並包含於 STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR 結構的 BytesPerPhysicalSector 字段中的相關信息。 本文稍後會更詳細地討論這一點。

大型扇區媒體的初始類型

存儲設備產業正在迅速加大工作，以轉換至這種新的進階格式類型的存儲設備，以用於具有 4 KB 實體扇區大小的媒體。 兩種類型的媒體將發佈到市場：

4 KB 原生： 此媒體沒有模擬層，而且會直接公開 4 KB 作為其邏輯和實體扇區大小。 這種新媒體的整體問題在於，大部分應用程式和操作系統不會查詢 I/O，並將 I/O 與實體扇區大小對齊，這可能會導致非預期的失敗 I/O。
512 位元組模擬（512e）： 此媒體具有上一節所討論的模擬層，並公開 512 位元組作為其邏輯扇區大小（類似於今天的一般磁碟），但會提供其實體扇區大小資訊（4 KB）。 這種新媒體的整體問題是，大部分的應用程式和操作系統都不知道實體扇區大小是否存在，這可能會導致許多問題，如下所述。
大型扇區媒體的整體 Windows 支援

下表記載了各種媒體及其報告部門規模的官方Microsoft支援政策。 如需詳細資訊，請參閱此 知識庫文章 。

仿真的運作方式：讀取-修改-寫入（RMW）

儲存媒體具有可修改實體媒體的特定單位。 也就是說，媒體只能以實體扇區大小的單位撰寫或重寫。 因此，未在此單元層級執行的寫入需要額外的步驟，我們將逐步解說下列範例。

在此案例中，應用程式必須更新位於512位元組邏輯扇區內之Datastor記錄的內容。 此圖說明記憶體裝置完成寫入所需的步驟：

如上所述，此程式牽涉到存儲設備的某些工作，可能會導致效能遺失。 若要避免這項額外的工作，應用程式必須更新為：

• 查詢實體扇區大小
• 確保寫入符合所報告實體扇區大小

雖然這一開始可能只是效能問題，但可能會有更嚴重的問題。 讓我們在下一節討論這一點。

復原：讀取-修改-寫入的隱藏成本

復原功能說明應用程式在會話之間復原狀態的能力。 我們已瞭解 512e 儲存裝置執行 512 位元組扇區寫入讀取-修改-寫入週期的必要專案。 讓我們看看如果媒體上覆寫先前實體扇區的程式中斷，會發生什麼情況。 後果會是什麼？

• 由於大部分硬碟已就地更新，因此實體扇區所在的媒體部分可能會因為部分覆寫而損毀不完整的資訊。 換句話說，您可以將它視為可能失去所有 8 個邏輯扇區（實體扇區邏輯包含的扇區）。
• 雖然大部分具有數據存放區的應用程式都設計成能夠從媒體錯誤中復原、遺失八個扇區或以另一種方式遺失八個認可記錄，可能會使數據存放區無法正常復原。 系統管理員可能需要從備份手動還原資料庫，甚至可能需要執行冗長的重建。
• 另一個更重要的影響是，另一個應用程式導致讀取-修改-寫入循環的行為可能會導致您的數據遺失，即使您的應用程式未執行！ 這是因為您的數據和其他應用程式的數據可能位於相同的實體扇區內。

考慮到這一點，應用程式軟體必須重新評估程式代碼中採取的任何假設，並注意邏輯實體扇區大社區分，以及本文稍後討論的一些有趣的客戶案例。

做正確的事（避免讀取-修改-寫入）

雖然某些記憶體廠商可能會在特定 512e 儲存裝置中引進一些層級的緩和措施，以嘗試緩解讀取-修改-寫入週期的效能和復原問題，但工作負載方面只有如此多的風險降低。 因此，應用程式不應依賴此風險降低作為長期解決方案。 此外，不保證所有類別的磁碟都會有此風險降低，也不能保證安全防護功能的設計良好。

此解決方案不是磁碟驅動器內風險降低，而是設計應用程式來執行正確的一組工作，以協助支援這種類型的媒體。 本節討論應用程式可能會有大型扇區磁碟問題的常見案例，並建議調查途徑來嘗試並解決每個問題。

問題 1：數據分割未對齊實體扇區界限

當系統管理員/使用者分割磁碟時，第一個分割區可能尚未在對齊的界限上建立。 這可能會導致所有後續寫入變成未對齊實體扇區界限。 從 Windows Vista SP1 和 Windows Server 2008 開始，第一個分割區會放在磁碟的前 1024 KB（針對磁碟 4GB 或更大磁碟，否則對齊為 64 KB），且對齊為 4 KB 實體扇區界限。 不過，鑒於 Windows XP 中的預設分割，第三方分割公用程式或 Windows API 使用方式不正確，所建立的數據分割可能無法對齊實體扇區界限。 開發人員必須確保使用正確的 API 來協助確保對齊。 建議的 API 有助於確保數據分割對齊如下所述。

建立新的磁碟區時，IVdsPack：：CreateVolume 和 IVdsPack2：：CreateVolume2 API 不會使用指定的對齊參數，而是使用操作系統的對齊值預設值（Windows Vista SP1 會使用 63 個字節，而 Windows Vista SP1 後會使用上述預設值）。 請改用 IVdsCreatePartitionEx：：CreatePartitionEx 或 IVdsAdvancedDisk：：CreatePartition API，針對需要建立數據分割的應用程式使用指定的對齊參數。

協助確保對齊正確的最佳方式是在一開始建立分割區時正確執行。 否則，您的應用程式必須在執行寫入或初始化時納入考慮，這可以是非常複雜的程式。

問題 2：未調整的寫入不符合實體扇區大小

最簡單的問題是，未壓縮的寫入與儲存媒體的回報實體扇區大小不一致。 另一方面，緩衝寫入會對齊頁面大小 4 KB，這恰巧是第一代大型扇區媒體的實體扇區大小。 不過，具有數據存放區的大部分應用程式都會執行未壓縮的寫入，因此必須確保這些寫入會以實體扇區大小的單位執行。

產生之應用程式 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引進了新的 API，可讓開發人員輕鬆地在其應用程式中整合 4K 支援。 這個新的 API 支援比下面討論的舊版 Windows Vista 和 Windows 7 方法更大量的案例。 此 API 可開啟這些呼叫案例：

• 從非特殊許可權的應用程式呼叫
• 呼叫任何有效的檔句柄
• 透過SMB2在遠端磁碟區上呼叫檔句柄
• 簡化的程序設計模型

API 的格式為新的資訊類別 FileFsSectorSizeInformation，且結構FILE_FS_SECTOR_SIZE_INFORMATION，如下所示：

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 引進 API，以查詢 AHCI 型儲存控制器所連結存儲設備的實體扇區大小。 從SP1起的 Windows 7 和 Windows Server 2008 R2（或 Microsoft 知識庫982018），這項支援會延伸至 Storport 型記憶體控制器。 如需示範應用程式如何查詢磁碟區實體扇區大小的程式代碼範例，請參閱 STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR結構。

雖然上述程式代碼範例可讓您取得磁碟區的實體扇區大小，但您應該先對報告的實體扇區大小進行基本理智檢查，再使用它，因為觀察到某些驅動程式可能不會傳回格式正確的數據：

• 請確定回報的實體扇區大小 = 回報的邏輯扇區大小 >;如果不是，您的應用程式應該使用等於所報告邏輯扇區大小的實體扇區大小
• 請確定報告的實體扇區大小是兩個的乘冪：如果不是，您的應用程式應該使用等於所報告邏輯扇區大小的實體扇區大小
• 如果實體扇區大小是介於512位元組和4 KB之間的兩個乘冪值，您應該考慮使用實體扇區大小四捨五入為回報的邏輯扇區大小
• 如果實體扇區大小是大於 4 KB 的乘冪值，您應該先評估應用程式在使用該值之前處理此案例的能力;否則，您應該考慮使用實體扇區大小四捨五入為 4 KB

使用此 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 的 Windows 7 SP1 982018
• 具有 Microsoft KB 的 Windows 7 982018
• 具有 Microsoft KB 982018 的 Windows Server 2008 R2 SP1 （v3）
• 具有 Microsoft KB 982018 的 Windows Server 2008 R2 （v3）
• 具有 Microsoft KB 的 Windows Vista 2553708
• 具有 Microsoft KB 的 Windows Server 2008 2553708

若要取得扇區大小資訊，請從提升許可權的命令提示字元呼叫 公用程式，如下所示：

fsutil fsinfo ntfsinfo <drive letter>

具有 512 位元組仿真的 4K 扇區磁碟具有 [每扇區位元組] 位元組設定為 512，而 [每實體扇區位元組] 位元組設定為 4096，如下所示：

4K 原生磁碟具有 [每扇區位元組] 和 [每實體扇區位元組] 字段，兩者都設定為4096，如下所示：

資源

• Windows 一般支持聲明
• Microsoft KB 982018
• 適用於 Windows 7 和 Windows Server 2008 R2 的 Hotfix
• HyperV 支援語句
• IOCTL_STORAGE_QUERY_PROPERTY控件程式代碼的一般資訊
• IOCTL_STORAGE_QUERY_PROPERTY控件程式代碼
• STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR 結構的一般資訊
• 用來描述Microsoft軟體更新的標準術語描述
• WDK 範例程式代碼，詳細說明如何在呼叫IOCTL_STORAGE_QUERY_PROPERTY控件程式代碼時，從STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR結構擷取回報的記憶體存取對齊資訊
• ImageX 命令行選項的一般資訊
• 支援 4 KB 扇區磁碟驅動器的 Intel 晶片組驅動程式需求