共用方式為

512 位元組模擬 (512e) 磁碟相容性更新

  • 發行項

平台

用戶端 - Windows Vista、Windows 7、Windows 7 SP1
伺服器 - Windows Server 2008、Windows Server 2008 R2、Windows Server 2008 R2 SP1

功能影響

嚴重性 - 高
頻率 - 高

描述

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

本主題介紹進階格式儲存裝置對軟體的影響、討論應用程式可協助支援這類媒體的功能，並討論可讓開發人員支援這些類型的裝置的基礎結構。 雖然本主題中呈現的材料提供改善與進階格式磁碟相容性的指導方針，但資訊通常會套用至具有進階格式磁碟的所有系統。 下列版本的 Windows 提供查詢實體扇區大小的支援：

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

如需其他詳細數據，請參閱 Windows 中大型扇區磁碟驅動器Microsoft支援原則的相關信息。

如需進階格式磁碟的詳細資訊，請連絡您的記憶體廠商。

邏輯扇區大小與實體扇區大小

在媒體格式引入這項變更方面，其中一個考慮是與目前市場上目前可用的軟體和硬體相容。 作為暫時解決方案，記憶體產業最初引進了模擬一般 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 作為其邏輯和實體扇區大小。 Windows 和其他大部分作業系統目前不支援此媒體。 不過，Microsoft正在調查在未來版本的 Windows 中支援這種媒體的可行性，並在適當時發出知識庫文章。
  • 512 位元組模擬（512e）：此媒體具有上一節所討論的模擬層，並公開 512 位元組作為其邏輯扇區大小（類似於今天的一般磁碟），但會提供其實體扇區大小資訊（4 KB）。 這是數個記憶體廠商目前正在向市場引進的。 這種新型媒體的整體問題在於，大部分的應用程式和操作系統都不知道實體扇區大小是否存在，這可能會導致許多問題，如下所述。

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

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

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

在512位元組邏輯扇區內升級數據記憶體記錄所需的步驟

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

  • 查詢實體扇區大小。
  • 請確定寫入符合回報的實體扇區大小。

讀取-修改-寫入的復原影響

復原功能說明應用程式在會話之間復原狀態的能力。 我們已瞭解 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，以改用指定的對齊參數。

協助確保對齊正確的最佳方式是在一開始建立分割區時正確執行。 否則，您的應用程式必須在執行寫入或初始化時考慮一致，這可能非常複雜。 從 Windows Vista SP1 起，這通常不是問題;不過，舊版 Windows 可以建立未對齊的數據分割，這可能會導致某些進階格式磁碟的效能問題。

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

基本問題是，未壓縮的寫入與儲存媒體的回報實體扇區大小不一致，這會在磁碟驅動器中觸發讀取-修改-寫入，進而造成效能問題。 另一方面，緩衝寫入會對齊頁面大小 – 4 KB ， 這恰巧是第一代大型扇區媒體的實體扇區大小。 不過，具有數據存放區的大部分應用程式都會執行未壓縮的寫入，因此需要確保這些寫入會以實體扇區大小的單位執行。

若要協助判斷應用程式是否發出未封存的 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。

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

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

使用此 IOCTL 取得實體扇區大小確實有數個限制：

  • 需要提高的許可權。 如果您的應用程式未以許可權執行，您可能需要如上所述撰寫 Windows 服務應用程式。

  • 不支援SMB磁碟區。 您可能也需要撰寫 Windows 服務應用程式，以支援這些磁碟區的實體扇區大小查詢。

  • 無法發出至任何檔句柄（IOCTL 必須發出給磁碟區句柄）。

  • 僅支援本文開頭附近的 Windows 版本。

認可記錄會填補到 512 個字節的扇區

具有數據存放區的應用程式通常會有某種形式的認可記錄，可維護元數據變更的相關信息，或維護數據存放區的結構。 為了確保扇區遺失不會影響多個記錄，此認可記錄通常會填補為扇區大小。 使用具有較大實體扇區大小的磁碟時，應用程式必須查詢實體扇區大小，如上一節所示，並確保每個認可記錄都會填補到該大小。 這不僅避免讀取-修改-寫入週期，也有助於確保如果實體扇區遺失，只會遺失一個認可記錄。

記錄檔會以未對齊的區塊寫入

更新或附加至記錄檔時，通常會使用未壓縮的 I/O。 有數種方式可協助確保這些更新正確對齊：

  • 在內部緩衝處理作業媒體的實體扇區大小更新，而且只有在實體扇區單位已滿時才會發出記錄寫入
  • 使用緩衝 I/O

問題 3：依賴 512 位元組扇區的檔案格式

某些具有標準檔案格式的應用程式（例如 VHD 1.0）可能會有這些檔案硬式編碼，以假設 512 位元組的扇區大小。 因此，更新和寫入此檔案會導致裝置上的讀取-修改-寫入週期，這可能會導致客戶的效能和復原考慮。 不過，有一些方法可讓應用程式支援在這種類型的媒體上運作，例如：

  • 使用緩衝來確保寫入是以實體扇區大小的單位執行
  • 實作內部讀取-修改-寫入，以協助確保更新以所報告實體扇區大小的單位執行
  • 如果可能的話，填補會記錄到實體扇區，如此一來，填補就會解譯為空白空間
  • 請考慮重新設計新的應用程式數據結構版本，以支援較大的扇區

問題 4：回報的實體扇區大小可以在會話之間變更

在許多情況下，裝載 Datastor 之基礎記憶體的回報實體扇區大小可能會變更。 其中最常見的情況是當您將 Datastor 移轉至另一個磁碟區，甚至是透過網路。 回報實體扇區大小的變更對許多應用程式而言可能是非預期的事件，而且可能會導致某些應用程式甚至無法重新初始化。

這不是最簡單的支援案例，這裡會提及為諮詢。 您應該考慮客戶的行動需求，並據以調整支援，以協助確保客戶不會受到 512e 媒體的負面影響。

4 KB 原生媒體

512 位元組的模擬媒體是512位元組原生和4 KB原生媒體之間的過渡步驟，我們預期會在512e之後不久發行4 KB原生媒體。 此媒體有數個重要影響，應該注意：

  • 邏輯和實體扇區大小都是 4 KB
  • 因為沒有模擬層，因此記憶體會失敗未對齊的寫入
  • 沒有隱藏的復原命中 – 應用程式無法運作或無法運作

雖然Microsoft目前正在調查未來 Windows 版本中這些媒體類型的支援，並在適當時發出 KB 文章，但應用程式開發人員應該考慮先佔先發制地提供這些媒體類型的支援。

關閉

在本文中，我們已討論大型扇區媒體在許多常見部署案例中引進的影響。 我們已看到「讀取-修改-寫入」的效能和復原影響、此媒體可以引入的一些有趣案例，以及它們可能會對軟體造成的問題集，最終會影響使用者。 記憶體產業正迅速轉換為具有較大扇區大小的媒體，而且很快客戶將無法購買具有傳統 512 位元組扇區大小的磁碟。

這是一份活生生的檔，其目的為開發人員協助瞭解此轉換。 您應該開始與個別組織、客戶、IT 專業人員和硬體廠商交談，討論大型扇區轉換，以及它如何影響您重要的案例。